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SUMMARY 


Problem 


The  Department  of  Defense  (DoD)  recognizes  that  the  Medical  Readiness  Strategic 
Plan  (MRSP-2001)  fails  to  address  the  need  to  develop  enhanced  capabilities,  within  the 
military,  for  providing  humanitarian  aid  in  operations  other  than  war  (OOTWs).  ‘ 

Objective 

Systematic,  in-theater,  on-site  data  collection  can  facilitate  DoD’s  strategic  planning 
for  US  military  medicine  in  OOTWs.  To  facilitate  that  process,  the  primary  objective  of  this 
investigation  was  to  review  the  triservice  patient  database  deployed  in  Zagreb.  This  review 
includes  (1)  a  description  of  the  origin,  rationale,  structure,  and  implementation  of  the 
database;  (2)  a  characterization  of  the  patients  who  used  medical  services  provided  by  the 
hospital,  and  a  description  of  their  rate  and  flow  through  the  system;  (3)  a  description  and 
enumeration  of  the  patient  conditions  presented  in  outpatient  visits  (OPVs),  admissions  and 
dispositions  (ADDs),  and  surgical  operations  (OPRs);  and  (4)  a  description  of  the  use  made  of 
available  medical  services  by  various  population  subgroups  of  interest. 

Approach 

In  this  report  we  present  (1)  a  review  of  the  structure  and  use  of  a  medical  patient 
information  database  designed  and  implemented  in  a  triservice  field  hospital  deployed  to 
Zagreb,  Croatia,  during  Operation  Provide  Promise,  and  (2)  a  descriptive  analysis  of  medical 
patient  data  that  were  collected  in  this  database  over  a  period  of  18  months  between 
September  1992  and  March  1994.  Because  they  are  derived  from  a  unique  US  involvement  in 
a  United  Nations-directed  multinational  peacekeeping  operation,  these  data  may  provide 
military  medical  planners  and  logisticians  with  useful  insights  into  the  specific  materiel,  skills, 
and  knowledge  requirements  demanded  by  such  missions. 

The  database  was  designed  and  written  in  Microsoft  ACCESS™.  After  reviewing 
the  structure  and  content  of  the  database,  inconsistencies  between  related  records  in  different 
tables  were  reconciled.  Numerous  simple  unidimensional  tabulations  were  performed  utilizing 
the  querying  capabilities  of  the  application.  More  complex  computations  were  performed  by 
exporting  relevant  data  to  Microsoft  Excel™  ^  or  to  SPSSx™.^ 

Results 


Nearly  16,000  medical  records  were  reviewed  for  this  report.  Data  pertaining  to 
demographic  characteristics,  OPVs,  ADDs,  and  OPRs  were  obtained  for  4612  military  and 
nonmilitary  patients.  Approximately  20%  (n=928)  of  these  were  admitted  as  inpatients  at 
least  once  and  approximately  9%  (n=408)  underwent  at  least  one  surgical  procedure  during 
the  18  months  between  October  1992  and  April  1994.  Due  probably  to  the  tenuous  cease-fire 
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that  was  in  place  during  this  time,  few  (less  than  2%  of  the  patient  population)  battle-  or  war 
related  injuries  were  treated.  Length  of  stay  for  inpatients  averaged  6.4  days,  but  more  than 
14%  of  1004  total  admissions  (n=141)  were  hospitalized  for  more  than  10  days. 

Conclusions 


This  patient  medical  data  from  the  field  hospital  in  Zagreb  will  be  useful  in  planning 
military  medical  materiel,  skills,  and  knowledge  requirements  in  future  OOTWs.  In  addition, 
and  perhaps  more  importantly,  the  effectiveness  of  the  data  collection  should  encourage  the 
development  of  a  servicewide  effort  to  collect  such  data  during  all  operations  and 
contingencies,  peacekeeping  or  otherwise.  Planning  based  on  both  data  and  anecdote,  rather 
than  on  anecdote  alone,  can  only  improve  medical  readiness  and  increase  the  quality  of 
medical  care  delivered  by  the  military  medical  services. 
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THE  FIELD  HOSPITAL  AT  ZAGREB: 


A  DATABASE  FOR  MILITARY  MEDICAL  RESOURCE 
PLANNING  IN  OPERATIONS  OTHER  THAN  WAR 

INTRODUCTION 

An  amended  draft  of  the  Medical  Readiness  Strategic  Plan  (MRSP)  2001  asks  the 
military  medical  services  to  develop  enhanced  capabilities  for  delivering  medical  services  in 
operations  other  than  war  (OOTWs).‘  OOTWs  include  various  organized  humanitarian  res¬ 
ponses  to  natural  disasters,  to  both  peacekeeping  and  peace-enforcing  operations  and  to  gen¬ 
eral  refugee  missions.  US  military  medicine’s  experience  in  such  missions  has  grown  during 
the  past  decade  but  remains  limited  when  compared  with  the  experience  of  such  nations  as 
Norway  and  France  where,  for  several  decades,  a  high  priority  has  been  placed  at  the  policy 
level  on  the  creation  and  maintenance  of  such  capabilities. 

Department  of  Defense  (DoD)  planning  for  OOTW-related  medical  missions  must  go 
forward  however,  for,  while  the  end  of  the  Cold  War  reduced  the  probability  of  large-scale 
global  conflict  between  superpowers,  economic  discontent,  as  well  as  resurgent  nationalism 
and  ethnocentrism  in  many  quarters  of  the  world  has  increased  the  frequency  of  local,  geogra¬ 
phically  constrained  disturbances.'*’^  The  Zagreb  database,  described  herein,  arises  out  of  the 
convergence  of  these  new  geopolitical  conditions  and  the  now  widespread  technological 
capability  within  the  services  to  electronically  collect,  process  and  store  information,  in-theater 
and  on-site.  The  Zagreb  data  can  help  logisticans  plan  for  future  OOTWs,  and  the  Zagreb 
database  points  toward  a  method  by  which  empirical  data  from  past  operations  can  be  used  to 
inform  the  planners  of  future  operations. 

BACKGROUND 

Between  October  1992  and  December  1995  the  US  Joint  Forces  deployed  a  60-bed 
Mobile  Army  Surgical  Hospital  (MASH)  to  the  edge  of  an  airfield  at  Camp  Pleso,  Zagreb, 
Northern  Croatia.  This  was  Operation  Provide  Promise,  and  its  defined  purpose  was  to  make 
24-hr  medical  support  available  to  more  than  25,000  personnel  under  the  United  Nations  com¬ 
mand  that  was  attempting  to  sustain  a  fragile  peace  on  the  war-ravaged  Balkan  Peninsula. 

The  mission  was  unique:  Not  only  was  it  a  triservice  endeavor  for  the  US  military  medical 
corps;  it  was  also  a  multinational  mission  in  which  the  field  hospital  operated  under  the 
leadership  of  Adm.  Smith,  Navy  Commander  in  Chief  in  Europe  and  commanding  officer  of 
the  Joint  Task  Force,  in  cooperation  with  the  United  Nations  Protective  Force  (UNPROFOR). 

Although  established  by  the  US  Army’s  212th  MASH  unit  (deployed  from  Wiesbaden, 
Federal  Republic  of  Germany)  it  was  never  intended  in  this  operation  that  the  facility  serve  in 
concordance  with  its  description  as  a  “mobile”  unit.  Nor  did  its  day-to-day  operation  ever  fit 
neatly  into  any  description  consistent  with  the  echelon  system  of  combat  casualty  manage¬ 
ment.  Rather,  throughout  Operation  Provide  Promise,  the  hospital  served  as  a  stationary  fac¬ 
ility  that  provided  definitive  treatment  for  only  a  very  few  severe,  war-related  injuries,  and 
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something  more  akin  to  garrison  care  for  the  multinational  forces,  for  civilian  UN  employees, 
and,  from  the  midpoint  of  the  deployment  on,  for  refugees  from  the  Croatian,  Bosnian,  and 
Macedonian  sectors  of  the  former  Yugoslavia. 

The  hospital  was  commanded  in  6-month  rotations  by  medical  units  from  the  US 
Army,  Navy,  and  Air  Force.  Between  October  1993  and  mid-March  1994,  during  the  dep¬ 
loyment  of  the  US  Air  Force’s  (USAF)  48th  ATH  (Air  Transportable  Hospital),  a  database 
was  designed  and  constructed  on  a  PC  platform,  to  record,  track,  and  store  detailed  medical 
data  for  patients  treated  at  the  facility.  Therefore,  a  substantial  amount  of  information  reflec¬ 
ting  activities  at  the  MASH  during  the  first  18  months  of  its  operation  was  methodically  col¬ 
lected,  collated,  and  archived  in  this  system.  In  response  to  the  amended  requirement  in 
MRSP-2001  to  develop  a  strategic  and  tactical  military  medical  capability  for  operations  other 
than  war,  both  the  database  and  its  contents  are  described  here.  The  data  should  assist  logis¬ 
ticians  in  their  thinking  about  the  construction  of  supply  and  equipment  assemblages  appro¬ 
priate  for  OOTWs  conducted  in  theaters  similar  to  Northern  Croatia.  The  applied  concept  of 
data,  systematically  collected  in-theater  and  on-site,  and  its  potential  uses  for  both  planning 
and  for  medical  and  administrative  management,  should  be  of  interest  to  military  policy¬ 
makers. 

THE  DATABASE 
Origins 

The  Zagreb  database  grew  out  of  an  interest  in  microcomputer-based  medical  infor¬ 
mation  systems  that  was  shared  by  a  highly  computer-literate  commanding  officer  and  a  staff 
physician,  both  of  whom  deployed  to  Camp  Pleso  with  the  48th  ATH  in  the  Fall  of  1993. 

They  also  shared  an  awareness  that  the  deployment  to  Zagreb  was  likely  to  be  of  historic  in¬ 
terest  to  US  military  medicine  in  that  this  hospital,  mobile  by  design  and  definition,  was  oper¬ 
ating  as  a  fixed  installation,  and  was  providing  definitive  care,  not  to  US  troops  wounded  in 
action,  but  to  a  diverse  population  of  United  Nations  troops  and  support  personnel  involved  in 
a  peacekeeping  effort. 

Additionally,  they  believed  that  clinical  care  of  patients  could  improve  with  the  use  of 
a  simple,  in-house  medical  information  system.  They  were  certain  that  the  day-to-day 
administration  and  management  of  a  deployed  facility  such  as  the  one  in  Zagreb  would  be 
made  easier  and  more  efficient  through  the  thoughtful  application  of  a  such  a  system,  even  if  it 
was  dependent  upon  relatively  obsolete  hardware  and  lacking  a  networking  capability.  Thus, 
they  decided  that  they  would  design  and  implement  a  database  that  would  allow  them  to 
systematically  document  the  medically  relevant  aspects  of  the  operation  both  for  the  historical 
record,  and  for  purposes  of  facilitating  the  patient-care/administrative  functions  of  the 
institution. 

In  administrative  terms,  it  quickly  became  obvious  to  the  commanding  officer  of  the 
48th  that  the  hospital  needed  a  more  effective,  efficient,  and  practical  system  of  communica¬ 
tion  with  Joint  Task  Force  (JTF)  headquarters  in  Naples,  with  the  office  of  the  UNPROFOR 
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Field  Medical  Officer  (FMO),  and  with  an  assortment  of  other  entities  up,  down,  and  across 
the  rather  complex  chain  of  command.  (This  was  not  an  insular  US  operation.  Therefore, 
communications  protocols  either  did  not  exist  or,  if  available,  were  sufficiently  convoluted  and 
ill-defined  as  to  impede  rather  than  facilitate  the  mission.)  Consequently,  even  though  not 
mandated  by  higher  echelons,  the  ad  hoc  design  and  implementation  of  the  database  became  a 
most  useful  exercise,  locally  pursued,  for  both  documentary  and  functional  purposes. 

Following  the  departure  of  the  48th  ATH  in  mid-March  1994,  command  of  the  field 
hospital  was  assumed  respectively  by  the  Navy’s  Fleet  Hospitals  Six  and  Five,  and  the  Air 
Force’s  60th  and  74th  Medical  Groups.  A  manual  describing  the  structure,  operation,  and 
maintenance  of  the  database  was  included  in  the  After  Action  Report  produced  by  the  48th 
ATH,  and  the  48th  staff  spent  time  during  transition  teaching  the  identified  personnel  from 
Fleet  Hospital  Six  about  its  day-to-day  operation.  In  December  1995,  the  hospital  was 
deconstructed  by  the  74th  Medical  Group  of  the  USAF.  The  microcomputers  and  hard  disks 
containing  whatever  additional  data  had  been  collected  by  the  commands  that  followed  the 
48th  ATH  were  returned  to  the  continental  United  States  (CONUS). 

Structure 

A  complete  and  detailed  description  of  the  database’s  design  and  operation  can  be 
found  in  the  After  Action  Report  of  the  48th  ATH  (see  Appendix  A).  The  brief  description 
that  follows  here  is  included  to  provide  a  framework  for  understanding  the  origins  of  the  data 
presented  later. 

Four  data  tables  were  created  to  contain  (1)  patient  demographic  information  (one 
record  for  each  patient  seen  at  the  hospital  for  any  reason);  (2)  data  on  outpatient  visits 
(OPVs;  one  record  per  visit  to  the  Emergency  Room  [ER],  to  the  Orthopedics  or  Physical 
Therapy  clinics  or  to  the  Dental  Clinic,  and  one  record  per  admission  to  inpatient  status);  (3) 
admissions  and  dispositions  data  (ADDs;  one  outpatient  record  for  each  admission,  whether 
for  an  overnight  inpatient  stay  or  for  a  same-day  surgical  procedure);  and  (4)  information  rel¬ 
ated  to  operations  and  anesthetic  events  (OPRs;  one  record  for  each  operation  performed). 
Logically,  a  patient  could  not  be  logged  into  the  patient  data  table  unless  he/she  was  logged  at 
least  once  into  the  outpatient,  admissions,  or  operations  table.  In  addition,  a  logged  operation 
required  a  logged  admission  (although  there  could  be  more  than  one  surgical  procedure  per 
admission),  and  a  logged  admission  required  a  logged  outpatient  visit. 

During  the  coding  and  entry  of  data  by  the  48th  ATH,  initial  OPVs  for  a  discrete  ill¬ 
ness  or  injury  were  recorded  in  each  clinic  when  the  patient/condition  presented  for  the  first 
time.  In  other  words,  a  patient  could  have  more  than  one  initial  visit  for  the  same  condition, 
but  not  to  the  same  clinic.  If,  for  example,  a  patient  presented  at  the  ER  with  a  knee  injury,  an 
initial  visit  was  logged  for  the  ER  on  that  date.  If  this  patient  was  then  referred  to  the  Phys¬ 
ical  Therapy  clinic,  his/her  first  visit  to  PT  for  this  particular  knee  injury  was  flagged  as  a  new 
case.  Although  subsequent  visits  to  PT  would  be  logged  as  follow-ups,  the  first  appointment 
was  always  coded  as  an  initial  visit  to  provide  the  clinic  with  incidence  data  for  its  services. 
This  convention  for  distinguishing  initial  from  follow-up  visits  led  to  some  confusion  in  the 
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form  of  overestimating  total  incidence  of  initial  visits  to  the  facility.  For  purposes  of  avoiding 
overestimation  of  OPVs  in  this  report,  initial  visit  status  was  confined  to  the  first  contact  by  a 
patient  with  the  facility  for  a  particular  illness  or  injury.  Any  subsequent  visit  to  any  clinic  for 
this  particular  problem,  was  defined  as  a  follow-up  visit. 

Table  1 

Database  Tables  and  Fields 


Tables 

Patient 

Data 

Outpatient 

Visits 

Admission/ 

Disposition 

Operations 

Fields 

^Patient  No. 

*Patient  No. 

*Patient  No. 

*Patient  No. 

Last  Name 

Visit  No. 

**Register  No. 

**Register  No. 

First  Name 

Date  of  Visit 

Date  Admitted 

OR  Case  No. 

Middle  Initial 

Time  of  Visit 

Time  Admitted 

Room  No. 

Epithet 

Clinic 

Date  Discharged 

Operation  Date 

Title 

Provider 

Time  Discharged 

Anesthesia  Start  Time 

Grade 

Smoker? 

Discharge  Clerk 

Anesthesia  End  Time 

Sex 

Flu  Shots? 

Primary  Provider 

Surgery  Start  Time 

DOB 

Tetanus  Shots? 

Serious  Illness? 

Surgery  End  Time 

SSN/AN 

Chief  Complaint 

Death? 

Nursing  Start  Time 

Nationality 

Accident? 

BI  or  DNBI? 

Nursing  End  Time 

Married? 

Accident  Category 

Reportable  Disease? 

Surgical  Diagnoses 

Religion 

Diagnoses 

Diagnoses 

ICD-9  Codes 

Race 

ICD-9  Code 

ICD-9  Code 

Urgency 

Branch 

Treatments 

Procedure 

Circulator 

Corps 

Primary  Dx  Category 

Procedure  Code 

Scrubbed 

Organization 

Follow-Up  Visit? 

Primary  Dx  Category 

Anesthetist 

Address 

Battle  Injured? 

Dx  Organ  Systems 

Surg  Assistant 

Mil/Civil? 

VIP? 

Major  Injury? 

Ophthalmologic? 

ETOH-Related 

Battle  Injury  Code 

Non  Battle  Injury  Code 

Admitted? 

Urgency  Level 

Walk  In? 

Dental  Tx  Category 

Referral? 

Anesthetic  Used 
Procedure 

Procedure  Codes 
Procedure  Types 
Surgeon 

Transfusion? 

Specimens? 

Drains? 

Implants? 

Remarks 

*  Unique  ID  linking  patient  records  across  four  tables 
**  Unique  number  linking  surgical  procedures  to  an  admission 

Data  entry  screens  were  designed  for  each  of  the  four  data  tables  to  facilitate  accurate 
and  complete  data  entry.  An  additional  22  lookup  tables  supported  the  pop-up  menus  con¬ 
nected  to  the  data  entry  screens  and  the  data  entry  process.  Table  1  of  this  report  contains  a 
list  of  all  fields  in  the  four  data  tables.  Cross-table  indexing  was  accomplished  through  the  use 
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of  unique  patient  identification  numbers  as  key  fields.  Registration  numbers  unique  to  a 
specific  admission  linked  each  operative  procedure  to  a  specific  patient  admission  in  the  ADD 
table. 


Patient  data  generated  during  occupation  by  the  48th  ATH  were  entered  on  non-net- 
worked  computers  located  either  in  the  patient  administration  area,  in  the  ER,  in  the  operating 
suite,  or  in  another  ancillary  site.  In  addition,  a  master  copy  of  the  database,  updated  daily, 
was  managed  by  the  system  operator  on  a  separate  computer.  Consistent  with  good  database 
management  and  security,  previously  entered  data  could  be  modified  only  on  the  master  copy. 

Data  collected  earlier,  by  the  212th  and  the  502nd  MASH  units  (in  the  form  of  hard¬ 
copy  documentation)  was  collated  by  staff  48th  staff  and  entered  into  the  system 
retrospectively  when  time  permitted.  Complete  ADD  records  were  found  for  both  the  212th 
and  the  502nd.  Emergency  room  (OPV)  logs  existed  in  complete  and  nearly  complete 
summary  form  for  the  two  earlier  commands,  respectively.  Complete  operating  room  record 
sets  were  available  for  both  earlier  units,  but  only  partial  records  were  obtained  for  orthoped¬ 
ics  and  physical  therapy  clinics.  Dental  data  were  entered  for  both  the  212th  and  the  502nd 
but  since  hard-copy  records  were  thought  to  be  incomplete,  caution  should  guide  any  inter¬ 
pretation  of  these  figures.  Scheduled  visits  with  the  hospital’s  mental  health  officer  were  never 
entered  into  the  database  because  of  confidentiality  issues,  although  the  psychiatrist  did  keep 
his  own  records  on  paper  so  that  summary  numbers  could  be  included  in  various  mandatory 
reports.  Data  on  psychiatric  diagnostic  classifications  described  later  in  this  report  come  not 
from  scheduled  mental  health  visits  during  the  deployment  of  the  48th  but  rather  from  after- 
the-fact  classifications  of  diagnoses  presenting  at  the  ER  during  the  course  of  all  three  deploy¬ 
ments. 


Numerous  query-generated  reports  also  were  designed  and  constructed  in  an  effort  to 
make  communications  between  administrative  and  command  entities  more  efficient,  as  prev¬ 
iously  mentioned.  Report  queries  extracted  data  from  the  tables,  copied  them  to  prepared 
formats  for  communication  with  the  JTF,  with  the  US  Air  Force  Europe/US  European 
Command  (USAFE/EUCOM),  and  with  the  United  Nations  Protective  Force  Field  Medical 
Office  (UNPROFOR/FMEDO).  Thus,  accurate,  current  and  finished  copies  were  efficiently 
printed  with  a  few  simple  keystrokes. 

Classification  of  Diagnoses 

Higher  echelons  in  both  the  UNPROFOR  and  US  chains  of  command  required  regular 
reports  on  the  illnesses  and  injuries  treated  at  the  hospital.  Each  had  its  own  template  for 
assigning  diagnoses  to  general  categories,  and  each  was  distinct  from  the  other  in  terms  of 
how  it  was  organized.  Fortunately,  however,  with  one  exception,  each  scheme  was  also 
inclusive  of  the  other,  in  terms  of  diseases  and  injuries  covered.  The  exception  was  related  to 
the  USAFE/EUCOM  category  of  “eye  illness/injury,”  which,  from  its  name,  can  be  seen  to 
join  ophthalmologic  injury  and  ophthalmologic  illness  into  one  category,  where  injury  and 
illness  are  always  separate  categories  in  the  UNPROFOR  diagnostic  scheme.  This 
incompatibility  turned  out  to  present  neither  practical  nor  programmatic  difficulties  because 
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the  numbers  of  ophthalmologic  illnesses  and  injuries  were  small,  and  because  in  both 
UNPROFOR  ^  USAFE  schemes  injuries  were  always  distinguished  from  illnesses  on  their 
respective  code  forms.  In  any  event,  the  database  was  designed  to  include  all  diagnostic  cate¬ 
gory  divisions  from  both  schemes  so  that  summary  data  could  be  unambiguously  produced  for 
either  command  according  to  its  respective  requirements  and  schedules. 

Line  officers  and  medical  professionals  at  the  local  level  had  classification  needs  of 
their  own.  For  example,  reportable  diseases  were  documented,  and  accidents  and  their  causes 
were  monitored  closely,  by  various  offices  at  Camp  Pleso.  In  addition,  medical  professionals 
at  the  48th  found  the  USAFE/UNPROFOR  diagnostic  classification  scheme  somewhat  lacking 
in  the  clinical  detail  they  believed  necessary  to  keeping  track  of  their  own  work.  With  no  nos- 
ologists  available  and  having  no  expertise  themselves  in  the  ICD-9  coding  that  might  have 
helped  them  in  their  tracking  efforts,  they  created  an  algorithm  based  on  a  diagnostic  organ 
system  classification  scheme,  which  permitted  the  generation  of  more  clinically  discernable 
subspecialty  statistics.  They  then  applied  this  algorithm  to  the  coding  of  their  own  data  as 
well  as  to  the  data  of  the  earlier  commands. 

DATA 

Patient  Demographics 

Between  October  10, 1992,  and  March  17, 1994, 4612  persons  were  either  seen  in 
one  of  the  hospital’s  outpatient  clinics,  admitted  to  one  of  its  60  beds  as  inpatients,  or  oper¬ 
ated  upon  in  one  of  the  hospital’s  four  operating  rooms.  More  than  6000  discrete  medical 
conditions  were  treated  during  the  course  of  9767  OPVs.  Over  18  months,  1004  admissions 
were  logged,  and  538  surgeries  were  listed  in  the  record  of  operations.  Table  2  contains  a 
tabulation  of  OPVs,  ADDs,  and  OPRs  by  unit  command  over  the  course  of  the  first  three 
deployments,  and  Figure  1  shows  the  hospital’s  outpatient  census  as  a  function  of  time. 

The  number  of  OPVs  per  month  is  seen  to  increase  by  a  factor  of  roughly  4.3  between 
mid-deployment  for  the  212th  MASH  in  January  1993  and  mid-deployment  for  the  48th  ATH 
in  January  1994.  One  would  naturally  expect  to  see  patient  numbers  increase  as  potential  users 
in  sectors  proximal  to  Camp  Pleso  became  aware  of  the  hospital’s  existence  and  as  operation 
of  the  new  facility  approached  optimal  efficiency  following  start-up.  However,  the  rate  of 
growth  seen  during  the  deployment  of  the  48th  ATH  was  extraordinary  and  may  have  had 
several  causes.  Firstly,  on  taking  over  command  from  the  502nd  MASH,  the  48th  ATH 
immediately  increased  the  number  of  daily  and  weekend  hours  during  which  medical  and 
dental  care  were  available  to  members  of  UNPROFOR  contingents  stationed  at  and  near 
Camp  Pleso  (ie,  sick  call  was  expanded  to  24  hr  a  day).  This  change  in  policy  had  a  salutary 
effect  on  political  relationships  between  the  US  hospital  and  the  non-US  contingents  that  were 
dispersed  throughout  Camp  Pleso.  During  earlier  deployments,  numerous  divisive  issues  had 
arisen  between  US  and  UN  personnel  that  had  the  affect  of  diverting  potential  patients  from 
the  contingents  away  from  the  emergency  room  and  primary  care  services  of  the  hospital. 
Secondly,  it  was  during  the  48th’ s  deployment  that  the  mission  of  Operation  Provide  Promise 
was  expanded  to  include  refugees  from  the  mortaring  of  Sarajevo  and  from  other  sectors  of 
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Table  2 


Outpatient  Visits,  Admissions,  and  Operations  by  Unit  Command 


212th 
11/15/92 
to  4/26/93 
(188  days) 

502nd 
4/27/93 
to  10/4/93 
(160  days) 

48th  ATH 
10/5/93 
to  3/20/94 
(166  days) 

ROW 

TOTALS 

(514  days) 

Patients 

(seen  for  first  time) 

1178 

1425 

2009 

4612 

Patient  Conditions 

(seen  for  first  time) 

1404 

2008 

3357 

6769 

Follow-Up  Visits 

216 

464 

2318 

2998 

Total  Visits 

1620 

2472 

5675 

9767 

Onerations 

206 

144 

188 

538 

Croatia,  Bosnia-Herzegovina,  and  Macedonia  where  overt  conflict  still  intermittently  broke 
out.  In  fact,  outreach  visits  to  refugee  camps  became  a  part  of  the  regular  schedule  for  the 
48th,  where  they  had  not  been  for  either  the  212th  or  the  502nd.  A  third  factor  that  certainly 
could  have  lowered  the  OPV  count  in  the  earlier  deployments  was  the  high  probability  that 
some  their  OPV  records  were  undoubtedly  lost  and/or  unavailable  for  input  by  staff  from  the 
48th  for  other  reasons. 


Numbers 

of 

Patients 


Months 


Figure  1.  Hospital  Outpatient  Census  as  a  Function  of  Time 
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Table  3 


Patient  Demographic  Data 


Patients 


N  % 


Outpatient 
Visits 
N  % 


Admissions  Operations 


N 


% 


N 


% 


Males 

4136 

(90) 

8495 

(87) 

927 

(92) 

500 

(93) 

Females 

476 

(10) 

1272 

(13) 

77 

(  8) 

38 

(  7) 

Military 

3503 

(76) 

7415 

(76) 

876 

(87) 

487 

(91) 

Nonmilitarv 

1109 

(24) 

2352 

(24) 

128 

(13) 

51 

(  9) 

Citizenship 

_US 

1002 

(22) 

3067 

(31) 

155 

(15) 

98 

(18) 

_Non-US/Non-Third^ 

3086 

(67) 

5741 

(59) 

697 

(69) 

377 

(70) 

_Third  World 

452 

(10) 

853 

(  9) 

136 

(14) 

47 

(  9) 

Unknown 

72 

(  1) 

106 

(  IL- 

16 

(,,2)_ 

16 

(  3) 

Note;  Percentages  are  derived  from  values  for  N  at  top  of  each  column. 

a.  Non-US/Non-Third  World  nations  include:  Argentina,  Australia,  Belgium,  Brazil,  China,  Canada,  the  Czech 
Republic,  Denmark.  Egypt.  Finland,  France,  United  Kingdom,  Germany,  Croatia,  Iceland,  India,  Iraq,  Ireland,  Italy, 
Jordan,  Lebanon.  Luxemborg.  the  Netherlands,  Norway,  New  Zealand,  Pakistan,  Poland,  Portugal,  Russia,  Saudi 
Arabia,  Switzerland.  Slovakia,  Spain,  Slovenia,  Sweden,  Ukraine,  Venezuela.  Third  World  Nations  include: 
Bangladesh,  Burma,  Columbia,  Ecuador,  Ethiopia,  Ghana,  Guyana,  Jamaica,  Kenya,  Libya,  Malaysia,  Nigeria.  Nepal, 
Peru,  the  Philipines,  the  Sudan,  Tunisia,  Uruguay,  Zaire. 


Table  4 

Age  Category  by  US,  Non-US/Non-Third  World 
and  Third  World  Citizenship 

US  Non-US  /  Third  Unknown  Row 
Non-Third  World  Totals 

World 

A.^0 

Class _ N  %  N  %  N  %  N  % _ 


17  or  younger 
18-30 

31-44 

45  or  older 

2(>1) 
359  ( 50) 
299  ( 42) 
59  (  8) 

32  (  2) 
1206  (  52) 
875  (  38) 

191 f  8) 

0(  0) 

79  ( 24) 
219  ( 67) 
29  (  9) 

0(  0) 

11  ( 25) 
24  (  55) 
9(20) 

34 

1655 

1417 

288 

Totals 

719 

2304 

327 

44 

3394 

Note:  Percentages  in  parentheses  are  column  percentages. 
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Comparisons  across  three  types  of  medical  service  utilization  (OPVs,  ADDs,  OPRs) 
for  males  versus  females,  military  versus  civilian,  and  US  versus  non-US/non-Third  World, 
and  Third  World  patients  are  presented  in  Table  3.  Note  that  non-US/non-Third  World  coun¬ 
tries  (ie,  the  European,  and  other  developed  nations)  contributed  roughly  two  thirds  of  all  pat¬ 
ients,  ADDS,  and  OPRs,  while  the  remaining  third  was  contributed  jointly  by  US  forces  and 
UNPROFOR  personnel  from  the  Third  World.  The  proportion  of  OPVs  contributed  by  non- 
Third  World/non-US  patients  (59%)  was  slightly  less  than  expected  due  to  the  fact  that  the 
largest  of  the  contingents  making  up  this  group,  the  French  and  the  British,  had  their  own  pri¬ 
mary  care  services  with  them  in  Zagreb.  At  the  same  time,  US  personnel  contributed  slightly 
higher  percentages  than  expected  to  OPV  totals  because  the  field  hospital  was  the  only  source 
of  treatment  for  the  troops  that  manned  it.  Table  4  presents  an  age  category  breakout  on  the 
73%  of  all  patients  treated  for  whom  reliable  birth  dates  were  captured.  Interestingly,  76%  of 
patients  from  the  Third  World  are  30  years  of  age  or  older,  a  third  again  as  many  found  in  that 
age  bracket  in  the  other  two  groups.  Anecdotal  reports  suggest  that  service  in  UN  military 
units  constitutes  an  economically  preferable  option  for  many  Third  World  citizens,  and  one 
might  speculate  that  garrison  medical  preparedness  for  older  persons  might  differ  from 
readiness  for  younger  age  groups.  Table  5  shows  the  contributions  made  to  OPV,  ADD,  and 
OPR  records  by  individual  nations  whose  personnel  were  treated  at  the  field  hospital. 

Outpatient  Visits 

Over  18  months,  9767  OPVs  were  logged  at  the  facility  for  4612  sick  or  injured  pat¬ 
ients.  Of  these,  69.3%  (6769  visits)  were  for  new  medical  conditions  (ie,  first  visit  for  a  new 
condition  in  a  given  patient)  while  the  remaining  2998  OPVs  (30.7%)  were  for  follow-up  of 
previously  logged  conditions. 

Table  6  contains  the  numbers  and  proportions  of  conditions  seen  during  outpatient 
visits  fitting  into  various  diagnostic  categories.  The  classification  scheme  is  inclusive  of  the 
combined  requirements  of  USAFE/EUCOM  and  UNPROFOR/FMEDO.  The  scope  of  each 
diagnostic  category  is  listed  at  the  bottom  of  the  table.  As  can  be  seen  in  the  first  row  of  data, 
more  than  one  third  of  all  visits  resulted  from  injuries,  both  related  and  unrelated  to  war.  More 
than  70%  of  the  outpatient  diagnoses  seen  during  the  period  in  review  fell  into  injury,  medical, 
and  respiratory  categories. 

Only  85  of  4612  patients  were  treated  for  war-related  injuries  (WRIs)  at  this  hospital 
during  the  first  18  months  of  Operation  Provide  Promise.  We  choose  to  speak  of  “war-related 
injuries”  here  rather  than  of  “battle  injuries”  or  “wounded  in  action”  because  so  few  injuries 
fit  the  strict  or  classical  definition  of  these  latter  terms.  For  purposes  of  this  report,  we  def¬ 
ined  WRI  to  include  any  injury  that  resulted  from  exposure  to  the  mechanisms  or  actions  of 
war  regardless  of  the  military  or  nonmilitary  status  of  the  wounded.  This  includes  the  usual 
injuries  that  result  from  overt  combat  as  well  as  those  injuries  resulting  from  the  detonation  of 
antipersonnel  and  antitank  mines,  for  example,  that  may  have  been  planted  long  before  the 
wounding  incident  and  that  occur  during  periods  of  tranquility. 
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Table  5 


Outpatient  Visits,  Admissions,  and  Operations  by  Nation 


Nation 

N 

OPVs 

Admits 

Operations 

Nation 

N 

OPVs 

Admits 

Operations 

United  States 

1002 

3067 

155 

98 

Germany 

16 

29 

1 

1 

France 

619 

967 

128 

72 

Philipines 

10 

26 

0 

0 

Great  Britain 

328 

625 

62 

27 

Ghana 

12 

23 

2 

0 

Croatia 

276 

613 

46 

22 

Brazil 

14 

21 

0 

0 

Canada 

269 

438 

93 

36 

Iceland 

4 

15 

0 

0 

Argentina 

141 

400 

36 

31 

Malaysia 

9 

13 

1 

0 

Netherlands 

235 

357 

26 

11 

Spain 

9 

13 

1 

0 

Denmark 

169 

313 

38 

19 

Pakistan 

6 

12 

0 

0 

Poland 

140 

277 

39 

40 

Lebanon 

4 

10 

0 

0 

Jordan 

158 

290 

43 

14 

Tunisia 

4 

9 

0 

0 

Sweden 

138 

269 

22 

10 

Burma 

2 

7 

1 

0 

Nepal 

104 

216 

38 

18 

India 

2 

6 

1 

1 

Norway 

125 

251 

14 

6 

Zaire 

1 

6 

1 

1 

Russia 

94 

161 

45 

35 

Ecuador 

2 

7 

0 

0 

Kenya 

129 

183 

38 

7 

Iraq 

5 

7 

0 

0 

Czech  Republic  43 

135 

23 

29 

Italy 

7 

6 

0 

0 

Nigeria 

74 

112 

30 

12 

Luxemborg 

3 

3 

3 

0 

Finland 

70 

119 

16 

7 

Peru 

2 

4 

0 

0 

Unknown 

78 

106 

15 

15 

Sudan 

1 

4 

0 

0 

Slovakia 

62 

112 

15 

4 

Slovenia 

4 

4 

0 

0 

Ukraine 

42 

104 

20 

5 

Uruguay 

3 

4 

0 

0 

Bangladesh 

37 

98 

7 

2 

Jamaica 

3 

3 

0 

0 

Egypt 

30 

89 

13 

3 

Venezuela 

2 

3 

0 

0 

Belgium 

35 

47 

17 

8 

China 

1 

2 

0 

0 

Austria 

21 

47 

0 

0 

Ethiopia 

2 

2 

0 

0 

Ireland 

25 

36 

2 

0 

Libya 

2 

2 

0 

0 

Portugal 

17 

31 

6 

0 

Saudi  Arabia 

2 

2 

0 

0 

New  Zealand 

10 

32 

1 

0 

Switzerland 

1 

2 

0 

0 

Columbia 

15 

26 

4 

3 

Guvana 

1 

1 

0 

0 

Totals  4612 

9767 

1004 

538 

Table  7  displays  causes  of  WRI  sorted  by  civilian/military  and  male/female  status. 
While  these  85  patients  went  on  to  generate  415  outpatient  visits  (initial  presentations  plus 
follow-ups;  4.2%  of  all  OPVs),  83  admissions  (8.3%  of  all  ADDs)  and  106  operations  (19.7% 
of  all  OPRs)  connected  with  their  war-related  injuries,  the  proportion  of  WRI  patients  (85  of 
4612  or  1.8%  )  versus  non-WRI  patients  (4527  of  4612  or  98.2%)  overwhelmingly  favored 
the  latter.  Military  personnel  accounted  for  seventy-two  of  85  WRI  patients.  Thirteen 
(15.3%)  were  civilians,  and  3  of  these  were  children  younger  than  17  years  of  age.  Several 
nonmilitary  patients  were  identified  as  civilians  working  for  UNPROFOR,  and  several  were 
refugees  from  camps  near  Sarajevo  and  Mostar.  Of  the  13,  9  were  Croatian,  and  2  were 
Portuguese.  One  Indian  and  one  citizen  of  Great  Britain  were  also  among  the  civilians. 
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Table  6 


Outpatient  Visits  by  Combined  USAFE/UNPROFOR 
Primary  Diagnostic  Categories 


Diasnostic  Catesorv 

N  of  Outpatient 
Visits 

%  of 
Total 

Injury  (Combined  War  &  Non-War-Related) 

3742 

38.3 

Medical 

1888 

19.3 

Respiratory 

1333 

13.7 

Dental 

726 

7.4 

Dermatological 

508 

5.2 

Gastrointestinal 

466 

4.7 

Surgical 

457 

4.7 

Ophthalmological 

364 

3.7 

Other 

87 

0.9 

Sexually  Transmitted  Diseases 

84 

0.9 

Psychiatric 

54 

0.6 

Unknown 

24 

0.2 

Substance  Abuse 

23 

0.2 

Heat/Cold  Injuries 

6 

0.1 

Fever  of  Unknown  Orisin 

5 

0.1 

Totals 

9767 

100% 

DEFINITIONS: 


Injury 


Medical 


Respiratory 

Dental 

Dermatological 

Gastrointestinal 

Surgical 

Opthalmological 

Other 

STDs 

Psychiatric 

Substance  Abuse 

Thermal  Injury 
FUO 


Those  requiring  hospitalization  or  surgery;  fractures,  sprains,  lacerations,  internal  injuries,  burns,  and 
thermal  injuries  other  than  sunburn;  nonenvenoming  animal  bites;  other  trauma  includes  battle,  non¬ 
battle,  occupational,  and  recreational  injuries 

Cardiac  problems,  such  as  chest  pain,  hypertension;  neurological  problems,  such  as  headaches, 
seizures,  syncope;  allergic  reactions,  including  systemic  reactions  to  venomous  bites/stings;  hepatitis; 
urogenital  illness  not  related  to  STD 

Upper  respiratory  infection,  colds,  bronchitis,  asthma,  pneumonia,  pharyngitis,  otitis,  sinusitis 
Dental  injury,  disease,  or  condition  requiring  dentist  intervention 

Viral  rashes,  lesions,  cellulitis,  fungal,  or  bacterial  infections;  contact  dermatitis  from  insect  bites;  skin 
ulcers  and  eschars 

Diarrhea,  gastroenteritis,  dysentery,  gastritis,  food  poisoning,  constipation,  intestinal  parasites 
Conditions  requiring  surgery  that  are  not  related  to  trauma  (eg,  appendicitis,  cholelithiasis) 
Conjunctivitis,  eye  infections/irritations,  corneal  abrasions,  foreign  bodies,  solar  injury,  trauma  not 
with  that  reported  under  “Injury” 

Disease,  illness,  injury  not  otherwise  classified 

Gonorrhea,  syphilis,  chlamydia,  genital  herpes,  PID,  venereal  warts/chancres 

Depression,  situational  reactions,  anxiety,  neurosis,  psychotic  reactions,  suicide  attempts,  behavioral 

reaction  to  medications  or  substance  abuse 

Abuse  of  alcohol  or  illegal  drugs,  including  marijuana,  prescribed  or  unprescribed  pharmaceuticals,  or 
other  substances 

Heat  strokes,  cramps,  exhaustion;  dehydration,  sunburn,  frostbite,  chilblains,  hypothermia 
Fevers  not  apparently  associated  with  a  diagnosable  illness  or  injury 
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Table  7 


Causes  of  War-Related  Injuries  in 
Civilian  vs.  Military  and 
Male  vs.  Female  Patients 


Gunshot 

Wound 

Mine 

Explosion 

Artillery 

Detonation 

Unknown 

Cause 

Row 

Totals 

Military 

24 

35 

7 

6 

72 

Civilian 

0 

5 

4 

4 

13 

Male 

23 

38 

9 

10 

80 

Female 

1 

2 

2 

0 

5 

Totals 

24 

40 

11 

10 

85 

Admissions 

Table  8  presents  absolute  numbers  of  persons  admitted  to  the  hospital  and  total 
numbers  of  admissions,  contrasting  males  with  females,  military  with  civilian  personnel  and 
patients  from  the  United  States  with  patients  from  Third  World  and  from  non-US/non-Third 
World  nations.  Eight  hundred  eighty-two  patients  (882)  accounted  for  1004  admissions  to  the 
hospital.  Of  the  882, 48  were  admitted  twice  and  8  were  admitted  3  times  over  the  span  of 
18  months.  Women  accounted  for  7.7%  (n=77)  of  all  admits.  Of  85  WRI  patients,  73 
accounted  for  83  admissions  (8.3%  of  all  admissions),  and  408  admitted  patients  (40.7%) 
underwent  some  sort  of  surgical  procedure.  Admitted  patients  came  from  36  different 
countries  and  were,  on  average,  an  estimated  29.2  years  of  age  (±8.6)  at  time  of  admission. 

One  hundred  fourteen  (12.9%)  civilians  were  admitted  to  inpatient  status,  and  36  of 
these  were  Croatian  nationals.  Twenty-one  admitted  civilians  were  citizens  of  Great  Britain, 
and  10  were  from  Denmark.  The  remaining  47  originated  in  16  different  countries. 

Table  9  presents  the  combined  USAFE/UNPROFOR  primary  diagnostic  categories  for 
admissions.  Category  definitions  can  be  found  in  Table  6.  It  can  be  seen  that  injuries,  medical 
and  surgical  diagnoses  respectively  constituted  the  three  largest  admission  subsets.  In  Table 
10  the  Injury  category  from  Table  9  is  further  broken  down  to  show  the  distribution  of  sub 
specialties  required  to  treat  the  admitted  injuries  in  WRI  and  non- WRI  patients.  That  93% 
and  87%  of  the  admissions  for  neurosurgically  and  orthopedically  treated  injuries  were  non¬ 
war-related,  confirms  the  nontraditional  nature  of  Operation  Provide  Promise. 
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Table  8 


Admissions  by  Subgroups  of  Interest 


Subgroup 

N 

Admitted 

Nof 

Admissions 

Males 

821 

927 

Females 

61 

77 

Military 

768 

876 

Civilian 

114 

128 

US  Citizens 

119 

155 

Non-US/Non  TW 

645 

699 

Third  World 

104 

136 

Unknown 

14 

14 

WRI 

66 

83 

Non-WRI 

816 

921 

Totals 

882 

1004 

Table  9 

Combined  USAFE/UNPROFOR  Diagnostic  Categories  at  Admission 


Diaenostic  Category 

N 

% 

Injury 

376 

37.5 

Medical 

190 

18.9 

Surgical 

189 

18.8 

Gastrointestinal 

73 

7.3 

Dental 

66 

6.6 

Respiratory 

52 

5.2 

Ophthalmological 

19 

1.9 

Psychiatric 

13 

1.3 

Dermatological 

10 

1.0 

Substance  Abuse 

10 

1.0 

Other 

3 

0.3 

Sexually  Transmitted  Diseases 

2 

0.2 

Heat/Cold  Problems 

1 

0.1 

Totals 

1004 

100% 
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Table  10 


Injury  Admissions  by  Treating  Clinical  Subspecialty 


Treating  Subspecialties 

Orthopedic 

Gen  Surgery 

Neurosurgery 

Ear,  Nose,  &  Throat 

Post-Op 

Burns  (Plastic  Surgery) 

Other 

Neurology 

Thoracic  Surgery 

Abdominal  Surgery 

Infectious  Disease 

Ophthamology 

Urology 

Oral  Surgery 

Medicine 

Rheumatology 

Vascular  Surgery _ 

Totals 


WRI 

Admissions 
N  % 
30  (13) 
28  (67) 
2  (  7) 
1  (  5) 
6  (67) 
1  (14) 

1  (14) 
0  (  0) 

2  (40) 

3  (75) 
1  (50) 
1  (50) 
0  (  0) 
0  (  0) 
0  (  0) 
0  (  0) 
1  noo) 

77  (20) 


Non-WRI 
Admissions 
N  % 

206  (87) 
14  (33) 
26  (93) 
21  (95) 
3  (33) 
6  (86) 
6  (86) 
5  (100) 
3  (60) 
1  (25) 
1  (50) 

1  (50) 

2  (100) 
2  (100) 
1  (100) 
1  (100) 
0  (  0) 

299  (80) 


Row 

Totals 

_ N_ 

236 

42 

28 

22 

9 

7 

7 

5 

5 

4 

2 

2 

2 

2 

1 

1 

_ l_ 

376  (100) 


A  total  of  6281  inpatient  days  were  accumulated  between  November  1992  and  mid- 
March  1994.  The  mean  length  of  stay  was  6.40  days  (SD=10.8),  with  a  range  extending  from 
0  (for  procedures  not  requiring  overnight  hospitalization;  ie,  same-day  surgeries)  to  152  days. 
While  the  modal  stay  was  in  fact  0  days,  141  of  the  1004  admissions  (14. 1%)  extended 
beyond  10  days,  and  415  admissions  (41.4%)  extended  beyond  the  3-5  day  limit,  which  com¬ 
monly  defines  Echelon  III  medical  facilities  (see  Table  1 1).  It  may  be  that  lengths  of  stay  for 
seriously  ill  or  injured  Third  World  citizens  were  intentionally  extended  relative  to  lengths  of 
stay  for  seriously  ill  and  injured  personnel  from  more  developed  parts  of  the  world  because 
continued  adequate  management  of  some  illnesses  and  injuries  were  often  unavailable  in  their 
home  countries.  It  has  also  been  suggested  that  delay  in  discharge  for  Third  World  patients 
simply  had  to  do  with  the  absence  of  evacuation  capabilities  in  their  home  countries.  What¬ 
ever  the  cause,  the  fact  of  extended  inpatient  stays  for  Third  World  patients  and  for  patients 
from  non-US/non-Third  World  nations  as  well,  was  confirmed  when  length  of  stay  for  the 
three  groups  was  compared  statistically.  Using  one-way  analysis  of  variance  mean  length  of 
stay  was  found  to  be  1.4  days  (SD±2.5)  for  US  inpatients,  7.0  days  (SD±1 1.7)  for  non- 
US/non-Third  World  inpatients,  and  9.5  days  (SD±10.0)  for  Third  World  inpatients.  These 
differences  were  significant,  with  F=15.87,  p=.0001  (US  <  non-US/non-Third  World  <  Third 
World:  Neuman-Keuls,  post  hoc). 
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Table  11 


Admissions:  Length  of  Stay 


Total  inpatient  days 

6281 

Mean  length  of  stay 

6.4  days 

SD 

10.8  days 

Maximum  stay 

152  days 

Minimum  stay 

0  days 

Median  stay 

4  days 

Detail 

Stay 

N 

% 

<24  hr 

163 

16.2 

1  day 

126 

12.5 

2  day 

108 

10.8 

3  day 

91 

9.1 

4  day 

79 

7.9 

5  day 

99 

9.9 

6  day 

51 

5.0 

7  day 

45 

4.5 

8  day 

27 

2.7 

9  day 

32 

3.2 

10  day 

20 

2.0 

>  10  day 

141 

14.0 

Missin2  data 

22 

2.2 

TOTALS  1004  100.0% 


Operations 

Surgeons  from  the  three  commands  completed  538  operations  on  408  individuals 
between  October  1992  and  March  1994.  Three  hundred  fifty-one  (351)  patients  underwent 
one  surgical  procedure  only,  while  57  patients  underwent  an  additional  187  surgeries  (num¬ 
bers  of  surgeries  in  patients  who  underwent  more  than  one  operation  ranged  between  2  and 
16.  The  latter  includes  numerous  anesthetized  wound  debridement  procedures  for  one  burn 
patient).  Table  12  presents  diagnosis  at  surgical  admission  for  all  patients  broken  out  by  cit¬ 
izenship.  Injury  as  a  diagnostic  category  accounted  for  56.7%  of  all  surgeries,  with  non- 
US/non-Third  World  personnel  accounting  for  82%  of  all  surgically  treated  injuries.  Ortho¬ 
pedic  surgical  procedures  were  the  type  most  commonly  employed  (n=242),  accounting  for 
45%  of  all  procedures  (see  Table  13). 
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Table  12 


Diagnoses  for  Patients  Admitted  for  Surgery  from  the  US, 
From  Non-US/Non-Third  World,  and  From  Third  World  Nations 


Primary  Non-US/  Third  Row 

Diagnoses  US  Non-Third  World  World  Unknown  Totals 


_N_ 

% 

N 

% 

N 

% 

_ N_ 

% 

N 

Injury 

23 

(  8) 

251 

(82) 

22 

(  7) 

8 

(  3) 

305 

Surgical 

52 

(32) 

85 

(52) 

22 

(13) 

4 

(  3) 

163 

Dental 

13 

(34) 

21 

(55) 

0 

(  0) 

4 

(11) 

38 

Medical 

4 

(36) 

7 

(64) 

0 

(  0) 

0 

(  0) 

11 

Respiratory 

1 

(10) 

9 

(90) 

0 

(  0) 

0 

(  0) 

10 

Gastrointestinal 

1 

(13) 

6 

(75) 

1 

(13) 

0 

(  0) 

8 

Ophthalmological 

0 

(  0) 

0 

(  0) 

1 

(100) 

0 

(  0) 

1 

Dermatological 

2 

(100) 

0 

(  0) 

0 

(  0) 

0 

(  0) 

1 

Other 

1 

rioo^ 

0 

(  0) 

0 

_X0) _ 

0 

_I_Q) _ 

1 

Totals 

97 

(18) 

379 

(71) 

46 

(  9) 

16 

(  3) 

538 

Table  13 


Operations  by  Surgical  Procedure  Type 

WRI  Surgeries  Non-WRI  Surgeries  Totals 
Surgical  Procedure  Type  N  % _ N _ % _ N _ 


Orthopedic 

70 

(29) 

172 

(71) 

242 

Plastic 

14 

(19) 

59 

(81) 

73 

Abdominal 

11 

(17) 

54 

(65) 

65 

Oral 

3 

(  6) 

48 

(94) 

51 

Genitourinary 

0 

(  0) 

30 

(100) 

30 

Ear,  Nose,  &  Throat 

0 

(  0) 

28 

(100) 

28 

General 

0 

(  0) 

17 

(100) 

17 

Rectal 

0 

(  0) 

14 

(100) 

14 

Anesthetic 

5 

(56) 

4 

(44) 

9 

Thoracic 

2 

(40) 

3 

(60) 

5 

Endotracheal 

0 

(  0) 

2 

(100) 

2 

Gynecological 

0 

(  0) 

1 

(100) 

1 

Ophthalmological 

1 

flOO) 

0 

(  0) _ 

1 

Totals 

106 

(20) 

432 

(80) 

538 
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DISCUSSION 


Of  interest  in  these  data  is  the  average  length  of  stay  for  admitted  patients  (6.4  days  ± 
10.8).  Beyond  any  confusion  around  the  issue  of  where  the  field  hospital  stood  in  terms  of  the 
echelon  system  of  care,  the  fact  is  that  the  average  length  of  stay  was  relatively  long.  This  was 
true  for  inpatient  citizens  of  Europe  and  other  developed  areas  (average  length  of  stay;  7 
days)  as  well  as  for  sick  and  injured  Third  World  patients  whose  average  inpatient  stay  lasted 
more  than  9  days.  Although  the  practice  of  keeping  very  sick  or  injured  patients  hospitalized 
for  extended  periods  caused  no  apparent  problem  in  Zagreb,  there  are  conceivable  scenarios  in 
which  an  unpredicted  renewal  of  overt  hostilities  might  create  a  mass  casualty  situation.  Such 
scenarios  could  create  dilemmas  for  medical  staff  responsible  for  deciding  what  to  do  with 
those  patients  occupying  beds  suddenly  needed  by  the  newly  injured.  Seriously  wounded  or 
sick  US  personnel  who  could  not  return  to  duty  would  of  course  be  evacuated  promptly  to 
medical  facilities  capable  of  providing  continuous  and  high  quality  care  even  if  that  meant 
evacuation  to  CONUS.  Questions  arise,  however,  regarding  guidelines  for  the  dispositon  of 
seriously  sick  or  wounded  Third  World  personnel  whose  home  nations  had  no  such  cap¬ 
abilities. 

A  second  issue  is  connected  with  the  fact  that  sick  or  injured  US  military  personnel  are 
generally  culled  from  deployments  to  operational  theaters.  In  multinational  operations  US 
military  medical  providers  can  expect  to  find  that  the  troops  and  personnel  of  other  nations  are 
not  necessarily  as  well  screened  before  deployment.  For  example,  several  patients  from  the 
Third  World  who  were  treated  at  Zagreb  were  found  to  be  HIV  positive,  and  in  general, 
dental  health  for  non-US  personnel  was  precarious.  Although  the  data  from  Zagreb  suggest 
that  general  level  of  demand  for  healthcare  services  was  not  greater  for  non-US  contingents, 
the  possibility  exists  that  US  military  medical  practitioners  could  face  both  nonlethal  and  lethal 
disease  in  multinational  operations  that  would  not  commonly  be  found  in  unilateral  missions. 
Logisticians,  if  provided  with  empirical  data  describing  the  health  profiles  of  nations 
participating  in  joint  operations,  could  augment  assemblages  of  medical  supplies  and 
equipment  to  anticipate  such  variations  as  may  occur. 

Also  of  note  in  the  Zagreb  data  is  the  elevated  number  of  accidental  injuries  treated 
during  the  18  months  between  October  1992  and  March  1994.  Between  35%  and  40%  of  all 
OPV  and  ADD  diagnoses  were  classified  as  injuries.  Of  3742  injury-related  OPVs  only  11% 
(415)  were  caused  by  mechanisms  of  war.  Of  376  admissions  for  injury,  only  22%  (83)  were 
war-related.  This  means  that  accidental  injuries,  whether  they  were  occupation-,  sports-  or 
recreation-related,  incurred  through  motor  vehicle  accident  and/or  connected  with  alcohol 
consumption,  accounted  for  89%  and  78%,  respectively,  of  all  injury-related  outpatient  visits 
and  admissions.  It  also  means,  at  least  in  theory,  that  these  “accidents”  were  preventable  to 
some  perhaps  significant  degree.  Analysis  of  the  causes  of  these  accidental  injuries  may  point 
to  some  useful  strategies  for  prevention. 
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CONCLUSION 


Sharp  et  al/’^  recently  summarized  the  history  of  US  military  involvement  in 
operations  other  than  war  since  World  War  II.  In  their  survey  they  cite  several  acknowledged 
authorities  who  have  supported  the  notion  that  it  will  be  in  our  best  interest  to  remain  avail¬ 
able  and  prepared  for  such  operations  for  the  foreseeable  future.  The  amended  MRSP-2001 
responds  to  this  advice  by  calling  for  the  development  of  OOTW  capabilities  in  the  military 
medical  services  by  the  beginning  of  the  next  century. 

Operations  other  than  war  present  military  medical  personnel  with  challenges  both  in 
the  planning  and  in  the  execution  that  are  different  in  some  fundamental  ways  from  the  chal¬ 
lenges  presented  by  armed  combat  between  organized  forces.  However,  planning  to  provide 
emergency  medical  assistance  in  OOTWs  requires  the  very  same  basic  knowledge  required  to 
plan  medical  operations  in  classical  warfare  scenarios  (ie,  some  estimate  of  the  rates  of  injury 
and  disease  per  some  number  of  potential  patients  per  some  period  of  time,  and  a  list  of 
patient  conditions  likely  to  be  seen  in  the  anticipated  theater  of  operation). 

The  Zagreb  database  presents  military  planners  and  logisticians  with  comprehensive 
empirical  data  collected  during  a  recent  OOTW:  data  that  describe  the  more  complex  demo¬ 
graphics  of  an  OOTW  treatment  population,  and  both  the  rate  and  flow  of  patients  through 
the  field  hospital,  as  well  as  the  patient  conditions  (ie,  diagnoses)  that  presented  at  the  hospital 
over  the  the  18  months  during  which  data  were  collected.  Although  these  data  would  prob¬ 
ably  be  inadequate  to  the  task  of  building  assemblages  for  an  OOTW  deployed  to  a  tropical 
area  or  to  a  desert,  they  can  be  useful  in  mounting  a  humanitarian  response  for  settings  resem¬ 
bling  this  one. 


In  sum,  the  data  collected  at  the  field  hospital  in  Zagreb  constitue  a  unique, 
systematically  collected  set  of  information  that  describes  the  ongoing  medical  activities  of  an 
operation  other  than  war.  Clearly,  it  is  a  resource  of  great  value  to  medical  planners  and 
logisticians. 
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Appendix  A 

After- Action  Report  of  the  48th  ATH 
Tab  H:  Patient  Database  Design 
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[Zagreb  Letteriiead] 

FROM:  Maj  Janet  T.  Martino 
SUBJ:  Tab  H  Patient  Database  Design 
TO:  After  Action  Report  and  Transition  Document,  21  Sept  93  -  17  Mar  94 


13  Mar  94 


1.  This  tab  is  divided  into  three  sections: 


Tab  HL  Database  Development.  This  section  addresses  the  rational  behind  the  wav  the 
database  was  designed  and  set  up  at  the  MASH.  It  includes  a  discussion  of  what  was 

recoi^en^tiOTs  constraints,  as  well  as  outstanding  problems  and 


b. 


c. 


Tab^.  Database  Management.  This  section  addresses  the  ‘care  and  feedin<^’  of  the 
database.  It  includes  detailed  instructions  on  the  ‘how  to’  of  data  entry  and  ^ 
categoraation  for  the  end  users,  and  intructions  for  verifying  data,  managing  a  pseudo¬ 
network,  and  mamtammg  the  database  file  for  the  System  Operators  (SysOps). 


Tab  H3.  Debase  Stracture.  This  section  is  comprised  of  reference  tables  detailin'^  the 
stracture  of  the^tabase.  This  information  will  allow  the  SysOps  to  understand  h^  the 
tables,  quenes,  forms,  and  macros  are  interconnected,  which  is  essential  to  the 
troubleshooting,  and  the  further  development  of  the  database. 
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[Zagreb  Letterhead] 


FROM:  Maj  Janet  T.  Martino 
SUBJ:  Tab  HI.  Database  Development 

TO:  After  Action  Report  and  Transition  Document,  21  Sept  93  -  17  Mar  94 


13  Mar  94 


1.  Personnel.  There  were  no  personnel  specifically  assigned  to  this  project,  with  the  exception 
of  the  project  officer.  However,  there  were  many  people  involved  with  data  entry,  who  were 
essential  to  the  project’s  success. 


DAFSC 

Title 

#  Involved 

Project  Function 

44M4 

Staff  Internist 

1 

Database  development,  SysOp 

4A0 

Patient  Admin. 

1  (Half  time) 

Assistant  to  the  SysOp 

4A0 

Patient  Admin. 

3  (Part  Time) 

Entry  of  patient  demographic  data  and  admission 

4N051 

ER  Technician 

varied 

Entry  of  outpatient  ER  visits 

4Y051 

Dental  Technician 

2  (Part  Time) 

Entry  of  Dental  visits 

4N171C 

Ortho  Technician 

1  (Part  Time) 

Entry  of  Orthopedic  Clinic  visits 

45072 

PT  Technician 

1  (Part  Time) 

Entry  of  Physical  Therapy  visits 

4654 

OR  Nurse 

1  (Part  Time) 

Entry  of  Operations 

2.  Phases 

a.  Transition  1  (21  Sept 

1993 -7  Oct  1993) 

complete,  electronic  data  collection  from  the  prior  deployed  groups. 
x?a  system  was  used  by  the  502nd  MASH,  and  presumably  by  the  212th 

MASH,  to  enter  data  on  the  admissions  to  the  hospital.  However,  this  data  was 

unrecoverable' in  any  case,  due  to  the  limitations  of 
the  1 AMMIS  system.  There  was  no  electronic  accounting  of  the  outpatient  visits. 

(2)  Hard  copy  documentation  of  patient  visits  was  found,  albeit  with  some  gaps.  In  some 
areas  the  documents  themselves  were  fairly  complete  and  available.  In  others,  only 
summary  logs  were  found.  For  other  areas,  there  were  either  no  records  found,  or 
such  an  incomplete  set  of  records  as  to  make  entry  pf  such  data  meaningless.  The 
following  table  outlines  the  status  of  the  recovered  records  by  section. 
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Clinic 

A&D 

ER 

OR 

Orthopedics 

PT 

Dental 

b.  Deployment 


Documentation  Available  for  Data  Entry 

Complete  record  set  for  the  212th  (15  Nov  92  -  27  Apr  93)  and 
502nd  (28  Apr  93-4  Oct  93)  ^ 

Complete  set  of  summary  logs  for  the  212th;  reasonably  complete 
record  set  for  the  502nd 

Complete  record  set  for  both  the  212th  and  502nd 

Some  records  from  the  502nd,  none  from  the  212th 

None  from  the  212th;  few  from  the  502nd 

None  from  the  212th;  scattered  few  from  the  502nd,  known  to  be 
mcomplete,  so  not  entered  in  the  database 


(1)  Data  Entry 

(a)  "^e  main  goal  and  primary  focus  during  this  time  was  to  retrieve  and  enter  all  of 
the  data  generated  by  the  MASH  since  its  inception.  A  no-frills  database 
application  was  constracted  using  Microsoft  ACCESS™  version  1.1  \  Because 
the  emphasis  was  on  getting  so  much  data  entered,  no  attempt  was  maHp  to  create 
a  polished  appUcation  whose  stracture  was  protected  from  the  end  users. 
Therefore,  some  training  for  the  data  enterers  was  required  and  the  System 
Operator  (SysOp)  had  to  continuously  peruse  the  data  entered  for  mistakes. 

(b)  The  magnitude  of  the  project  was  enormous  for  our  resources,  involving  entering 
nearly  16,000  records.  Approximately  2000  -  2200  man-hours  went  into  the 
database  over  five  month’s  time.  Of  this,  approximately  half  of  those  hours  were 
for  data  entry,  the  rest  being  used  for  database  management  and  development. 

Without  the  backlog  of  data  to  input,  data  entry  alone  requires  approximately  12 
hours  per  week.  rr  j 

(c)  Four  data  tables  were  created  which  contain  information  on  patient  demographics, 
mpaUMt  visits  (to  the  Emergency  Room,  and  Orthopedic,  Physical  Therapy  and 
^ntal  Clinics),  admissions  and  dispositions,  and  operations  /  anesthetic  events^. 
Copies  of  toe  datable  were  put  on  computers  located  at  the  main  data  entry 
points:  Patient  Administration,  the  Emergency  Room,  and  the  Operating  Suite, 
^e  master  copy  was  kept  on  the  computer  used  by  the  SysOp  for  housekeeping 
chores  and  further  development.  Since  these  computers  were  not  connected  ov^  a 
network,  a  tremendous  effort  was  required  of  the  SysOp  to  transfer  the  entered 
data  between  the  different  computers  and  to  keep  the  copies  synchronized.  The 
alternative  was  to  restrict  all  data  entry  to  just  one  machine,  which  would  have 
created  an  unacceptable  bottleneck.  As  it  was,  new  records  could  only  be  entered 
in  one  appropriate  outlying  computer,  and  all  editing  of  previously  entered  data 
could  only  be  done  on  the  master  copy.  Therefore,  version  control  was  another 
critical  issue  for  the  SysOps. 

(d)  In  order  to  simplify  the  management  of  outpatient  visit  data  entry,  the  initial  plan 
called  for  all  patient  contacts  with  the  hospital  to  be  logged  in  through  the  ER, 
who  would  then  refer  the  patient  to  the  appropriate  clinic  for  treatment.  In 
practice,  this  plan  went  by  the  wayside  almost  immediately,  as  the  other- clinics 


»  ACCESS™  is  available  either  as  a  separate  software  package  or  as  part  of  Microsoft  Office  Pro™  for  Windows™ 
The  full  description  of  the  structure  of  the  database  is  given  in  Tab  H3.  Database  Structure. 

^  These  issues  are  discussed  in  detail  in  Tab  H2.  Database  Management. 
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began  seeing  patients  directly  and  scheduling  their  own  follow-up  visits, 
completely  bypassing  the  ER.  This  added  several  levels  of  complexity  to 
managmg  the  database:  i'  j 

1.  Another  data  entry  point  for  the  Outpatient  Visits  table  had  to  be  created,  and 
a  cPMge  m  the  numbering  scheme  developed,  in  order  to  allow  entry  into  a 
smgle  data  table  from  two  separate  points.  It  also  necessitated  further 
checking  to  be  done  to  eliminate  duplicate  entries^.  The  entry  of  these  records 
was  accomplished  by  setting  up  another  computer  for  the  entry  of  the 
backlogged  records,  so  that  there  would  be  fewer  conflicts  for  time  on  the 
oraputep.  Current  records  for  those  cUnics  are  being  entered  on  the  Patient 
Admimstration  computer,  since  the  volume  is  relatively  small;  also  this  avoids 
having  to  update  a  fifth  station  with  new  patient  dafg  entries. 

^isit’  had  to  be  redefined  from  ‘More  than  one 
visit  to  the  I^SH  for  a  given  problem’,  to  ‘More  than  one  visit  to  a 
particular  clinic  fox  a  given  problem.’  While  this  allows  individual  clinics  to 
separate  the  incidence  of  an  illness  from  the  workload  involved  in  treating  the 
illness  le.,  new  pauents  vs.  follow-up  visits,  it  introduces  an  inaccuracy  when 
nUnKf  mash  data,  since  a  patient  can  be  logged  in  as  having  a 
new  problem  m  more  than  one  clinic^.  For  example,  a  patient  with  an  injury 

^  given  the  initial  treatment  and  referred  to  the 
follow-up.  Subsequently,  he  might  be  referred  to  the 
Physical  Therapy  Clmic  for  rehabilitation.  Thus  the  single  injury  has 
generated  pree  ‘new’  visits.  To  limit  the  damage,  we  deleted  the  ER  record  of 
patients  referred  to  another  clinic  for  initial  treatment,  as  happened  often  with 
dental  problems.  Also,  this  situation  was  relatively  infrequent,  with  the 
e:peption  of  referrals  between  Orthopedics  or  the  ER  to  Physical  Therapy. 
These  referr^s  account  for  25  -  30%  of  the  ‘new  patient’  visits  to  Physical 
inerapy,  leading  to  a  significant  overstatement  when  reporting  global  data 
^cident  reports.  This  problem  had  not  been  worked  out  at  the  time 

the  data  for  this  after  action  report  was  extracted,  and  so  is  reflected  in  that 
report. 

(e)  Another  ch^ge  to  the  original  plan  was  to  separate  the  entry  of  the  patient 
demographic  data  from  the  entty  of  the  clinical  data  generated  by  a  visit.  There 

simpUfy  the  data  entry  procedure 
for  the  ER  ^d  other  outpatient  clinic  staff,  who  had  the  bulk  of  the  workload,  and 
vanable  skill  levels.  The  second  was  to  train  a  smaller  number  of  people  in 
searchm^eclmiques  and  the  data  entry  conventions  needed  to  avoid  duplicate 
entnes  .  This  function  was  taken  over  by  the  Patient  Administration  staff,  one  of 
whom  learned  enough  to  act  as  an  assistant  to  the  SysOp.  Eventually,  all  patients 
were  signed  in  at  Pauent  Administration  either  before  or  after  their  visit,  which 
flowed  them  to  venfy  that  the  data  was  complete  and  correct.  The  only  drawback 
to  this  w’as  that  moving  the  information  from  the  PATIENT  DATA  table  on  the 
Patient  Admmstration  computer  to  the  outlying  data  entry  points  became  time 
sensitive,  since  no  new  patient’s  clinic  data  could  be  entered  until  the  table  with 
the  patient  s  demographic  information  had  been  updated  on  that  computer.  To 
avoid  causing  a  work  stoppage  in  data  entry,  these  tables  were  updated  every  two 


‘‘ibid. 

5  l^amples  of  reports  based  upon  global  data  are  the  USAFE/EUCOM.  the  UNPROFOR,  and  the  Accident  Reports, 
ere  are  few  data  entry  vdidaUons  set  up  in  this  application  to  allow  easier  transfer  of  records  between  versions. 
One  such  validation  forbids  duplication  of  UN  ID  numbers  or  of  social  security  numbers  for  American  pauents. 
However,  duplications  have  occurred  when  spacing  conventions  between  the  letters  and  digits  of  a  UN  number 
were  not  foUowed,  when  the  patient’s  UN  ID  number  has  changed,  or  an  American  patient  was  entered  once 
using  his  UN  ID  number  and  a  second  time  using  his  SSN.  Data  entry  conventions  are  laid  out  in  Tab  H2 
Database  Management. 
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or  three  days  by  the  SysOp.  Also,  since  there  was  a  weekly  report  due  to  US  AFE 
/  EUCOM,  an  effort  was  made  to  have  data  entry  complete  on  all  current  patients 
by  the  end  of  each  weekend. 

(f)  The  only  exception  to  the  rule  that,  “editing  of  previously  entered  records  must  be 
done  on  the  master  copy  on  the  SysOp’s  computer,”  was  with  the  A&D  DATA 
table.  Since  an  entry  could  not  be  completed  until  the  patient  was  discharged, 
sometimes  weeks  later,  these  records  regularly  had  to  be  updated.  Since  the 
Patient  Administration  staff  was  already  using  one  computer  to  enter  all  patient 
deinograpinc  data  and  adimssions,  and  using  that  computer  to  search  on  patient 
entries  during  the  day,  it  seemed  to  make  sense  to  declare  that  the  A&D  DATA 
table  on  that  computer  was  the  master  copy.  Therefore,  records  in  it  could  be 
edited  in  order  to  add  disch^ge  dates  and  to  update  the  diagnosis  and  procedures 
done  during  the  hospitalization.  This  also  provided  an  additional  point  at  which 
the  (kta  could  be  reviewed,  corrected  and  categorized.  This  was  technically 
possible  only  because  this  table  could  be  overwritten  in  the  main  copy  without 
breaking  and  reforming  joins  in  the  database. 

(g)  Another  problem  was  encountered  when  patients  were  admitted  directly  from  a 
clinic  without  an  outpatient  visit  entry  having  been  logged.  While  it  is  clear  that 
A&D  data  belong  in  a  separate  table  from  outpatient  visits,  there  was  no 
consistency  to  when  an  entiy  appeared  in  both  the  inpatient  and  outpatient  tables 
md  when  not.  This  made  generating  reports  on  global  patient  clinical  statistics 
impossible,  since  adding  the  two  tables  would  lead  to  overstatement  and  drawing 
from  the  outpatient  table  alone  would  be  incomplete.  This  was  addressed  for  the 
entries  of  patients  seen  during  this  deployment  by  ensuring  that  outpatient  entries 
are  being  generated  for  all  admissions.  However,  for  the  prior  two  deployments 
the  two  tables  will  Imve  to  be  compared  and  entries  created  in  the  outpatient  table 
where  they  are  missing.  Once  created,  these  entries  are  flagged  in  the  outpatient 
table  as  having  been  admitted,  so  they  can  be  readily  separated  out. 

(h)  A  similar  problem  occurred  with  the  entry  of  minor  procedures  done  in  the  OR, 
such  as  endoscopy,  where  admission  to  the  hospital  was  not  required,  and  no 
outpatient  visit  was  ever  logged  through  the  ER.  This  was  resolved  by  having 
Patient  Administration  admit  them  as  a  same-day  surgery,  and  by  creating  an 
entry  in  the  outpatient  table. 

(i)  Vis^  to  the  Mental  Health  Clinic  were  never  entered  into  the  database  because  of 
confidentiality  issues,  particularly  involving  visits  by  members  of  the  US 
contingent.  A  record  of  these  visits  was  kept  on  paper,  coded  by  the  patient’s 
initials,  but  containing  their  social  security  number.  Adding  them  to  the  database 
under  their  initials  would  have  created  duplicate  patient  entries,  but  the  numbers 
were  small  enough  to  have  had  a  negligible  impact.  The  social  security  numbers 
would  have  had  to  be  changed  since  the  database  would  not  allow  duplicates  of 
Aese,  and  this  could  have  acted  as  a  flag  to  determine  the  total  number  of 
duplicate  entries.  In  the  end,  the  psychiatrist,  who  was  a  sole  provider,  decided 
not  to  enter  these  records  into  the  database.  He  was  able  to  provide  a  count  of  the 
visits  for  each  month  which  was  manually  entered  into  the  reports  of  disease 
categories  to  EUCOM  and  UNPROFOR. 

(2)  Data  categorization 

UNPROFOR  /  FMEDO  categorization  schemes.  The 
USAFE  /  EUCOM  categonzation  scheme  was  apparently  cast  in  stone.  A  weekly 
t&pon  of  US  patients  only,  broken  down  into  these  categories  was  required  (see 
Tab  H  1.1 )  and  sent,  even  though  the  meaningfulness  of  such  limited  data  was 
quesaoned  For  the  UNPROFOR  report,  due  monthly  (see  Tab  H  1.2),  the  SysOp 
worked  with  the  Assistant  Forces  Medical  Officer  to  develop  a  categorization 
scheme  which  was  more  pertinent  to  this  deployment  and  not  totally  incompatible 
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with  the  EUCOM  scheme.  As  the  following  table  shows,  with  the  exception  of 
eye  injunes,  each  categoiy  in  one  scheme  is  in  its  entirety  either  a  subset  or  a 
supereet  of  a  category  in  the  other  scheme.  By  including  all  of  the  category 
divisions  from  both  schemes,  the  database  can  produce  sununaiy  Hgta  which  can 
be  used  for  either  report.  The  EUCOM  category  of  Eye  Injuries  /  Illnesses  is  the 
only  exception  to  this  since  injuries  belongs  to  one  UNPROFOR  category  and 
illnesses  to  another.  But,  because  the  Eye  category  is  also  flagged  for  injury  type 
according  to  the  UNPROFOR  scheme,  the  database  can  make  the  distinction 
between  eye  injuries  and  illnesses.  However,  this  has  not  been  programmed  into 
the  reports,  since  the  number  of  cases  is  so  small  that  they  can  be  to  the 
fin^  figures  manually.  These  categories  were  assigned  by  the  professional  staff 
mcluding  the  Military  Public  Health  Officer,  after  the  records  were  entered. 
Because  a  level  of  clinical  expertise  was  required  to  assign  the  categories 
appropriately,  this  was  not  left  to  the  technicians. 
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CATEGORIZATION  SCHEMES  FOR  DISEASE  /  INJURY  TYPES 


USAFE/EUCOM 

UNPROFOR  /  FMEDO 

1  COMBINED 

Heat  /  cold 

Climatic  Disease 

Heat  /  Cold 

Dental 

Dental 

Dental 

Medical  Illnesses* 

Medical 

Other  Medical 

Dermatological  Illnesses 

Dermatological  Illnesses 

Respiratory  Illnesses 

Respiratory  Illnesses 

Gastrointestinal  Illnesses 

Gastrointestinal  Illnesses 

Fevers  of  Unknown  Origen 

Fevers  of  Unknown  Origen 

Sexually  Transmitted  Disease 

Sexually  Transmitted  Disease 

Surgical.  Non  traumatic 

Sursical.  Non  traumatic 

Psychiatric  Illnesses 

Psychiatric  Illnesses 

Psychiatric  Illnesses 

Substance  Abuse 

Substance  Abuse 

Orthopedic/Surgical  Injuries 

Injuries 

Injuries 

Major  vs.  Minor 

Major  vs.  Minor 

Battle  Injuries 

Battle  Injuries 

Gunshot  wound 

Gunshot  wound 

Mine 

Mine 

Artillary 

Artillary 

Other 

Other 

Non  -  Battle  Injuries 

Non  -  Battle  Injuries 

Vehicular 

Vehicular 

Sports 

Sports 

Other 

Other 

_  Alcohol  related  (yes  /  no)  Alcohol  related  (yes  /  no) 

Eye  Iniuries  and  Illnesses  Eve  Injuries  and  Illnesses 

*  Includes  non-trauma  surgical  illnesses 


(b)  Professional  Staff,  and  other  local  categorization  schemes. 

1.  Accident  identification  and  determination  of  causes.  An  extensive  review  of 
dl  records  available  was  done  by  the  Safety  Officer  to  identify  accidental 
injuries  and  categorize  their  causes.  The  categories  used  were  Falls,  Fights, 
Industrial  (work  related).  Miscellaneous,  Motor  Vehicle  Accidents,  Sports 
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Injuries,  and  Unknown.  Battle  injuries  were  not  counted  as  accidents.  The 
effort  that  was  expended  to  determine  the  circumstances  surrounding  each 
accident  was  justified  because  the  information  gained  was  also  used  to 
categorize  the  injury  type  for  the  UNPROFOR  injury  report.  The  ability  to 
assign  categories  varied  with  the  amount  of  information  available.  Therefore, 
the  data  are  fairly  complete  for  the  48th,  since  the  technicians  were  instructed 
to  note  the  circumstances  of  the  accident  when  signing  the  patient  in.  The  Hatn 
are  incomplete  for  the  502nd,  but  since  the  actual  medical  records  are 
available,  the  designation  of  an  accidental  injury  could  be  determined,  and  in 
some  cases  a  cause  assi^ed.  Since  nothing  was  available  from  the  212th  but 
summary  logs  of  the  patient  visits,  the  accidental  nature  of  the  injury  could 
only  be  surmised  and  no  causal  factors  identified. 

2.  Dia^osis  by  (sub)specialty  or  organ  system  (See  Tab  H  1.3).  These  are 
applied  to  inpatient  diagnoses,  by  the  professional  staff,  and  will  be  used  to 
group  inpatient  diagnoses.  Since  each  patient  may  have  many  diagnoses, 
statistics  c^  be  generated  on  all  problems  treated  at  this  facility,  as  well  as  be 
limited  to  just  the  primary  diagnosis. 

3.  Surgical  procedure  types  (See  Tab  H  1.3).  Applied  to  surgical  procedures 
performed  in  the  OR,  to  break  these  down  according  to  surgical  specialty  or 
body  region  regardless  of  the  specialty  of  the  surgeon  performing  the 
procedure.  These  categorieS'^are  mirrored  in  the  diagnoses  categorization  in 
item  2.  immediately  above 

4.  I^ntal  Treatment  Categories.  T^ese  were  developed  by  the  dentist  for  use  in 
the  outpatient  Dental  Clime  visit  entries.  They  are  applied  by  the  dental 
technician  who  does  the  data  entry  and  verified  by  the  dentist  (see  Tab  H  1.3). 

5.  ICD-9  coding  for  inpatient  diagnoses  and  surgical  procedures.  Fields  have 
been  made  to  enter  this  data.  However,  since  none  of  our  Patient 
Admmistration  techmeians  had  any  background  in  coding,  these  were  not 
entered  for  the  48th.  The  502nd  and  212th  were  able  to  code  much  of  their 
information  and  this  has  been  entered. 

6.  Reportable  Diseases.  There  are  extensive  listings  of  reportable  diseases  from 
both  EUCOM  and  the  FMEDO’s  office  (see  Tab  H  1.4),  most  of  which  are 
rarely,  if  ever,  seen  here.  Therefore,  no  categorization  has  been  attempted, 
beyond  creating  a  flag  field  for  noting  the  occurrence  of  a  reportable  disease. 
Eveii  with  such  a  limited  categorization  difficulties  arise  due  to  lack  of  data 
and  imprecise  terminolgy^. 

(3)  Reports 

(^)  USAFE  /  EUCOM.  Weekly  report  of  diagnostic  categories  on  US  patients  only. 
Due  to  the  high  frequency  of  this  report,  and  to, the  time  required  to  get  the  data 
from  all  of  the  clinics  inputed  and  checked  for  omissions  and  duplications,  much 
of  this  report  was  generated  by  hand  counts  and  are  of  questionable  accuracy. 
When  we  questioned  the  need  for  sending  weekly  reports  to  USAFE  Military 
Pubhe  Health  office,  we  were  told  that  the  tasking  was  from  EUCOM  (or  even 
higher  up  the  chain)  and  could  not  be  changed.  COL  Elliot  Pearlman,  the  Deputy 
Surgeon  at  EUCOM,  was  pleased  with  the  reports  he  was  getting.  Once  the  data 
entry  is  complete,  new  copies  of  the  reports  will  be  generated  to  correct  any 
iriaccuracies.  At  that  time,  the  issues  of  the  frequency  of  this  report,  the  limitation 
ot  US  patients  only,  and  the  inadequacies  of  the  categorization  scheme  will  be 
addressed.  The  goal  is  to  get  them  to  accept  the  full  monthly  report  based  upon 


^  For  example:  does  a  diagnosis  of  Acute  Gastroenteritis  signify  diarrhea,  a  reportable  disease?  Is  a  Flu-like 
Syndrome  an  upper  respiratory  infection  with  systemic  complains? 
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the  combined  categories,  perhaps  with  the  US  patients  broken  out  in  a  separate 
report. 

(b)  UNPROFOR  /  FMEDO  TOs  is  a  monthly  report  first  due  for  Dec  1993.  It 
coi^ists  of  one  report  of  diagnoses  grouped  by  general  disease  categories,  and 
broken  down  by  new  vs.  follow-up  visits,  and  another  report  which  categorizes 
mjunes  by  the  scheme  m  item  2.b.(2)(a)  above.  As  mentioned  before,  the 
breakdown  of  eye  injuries  vs.  illnesses  has  not  yet  been  automated,  but  this  could 
be  accomplished  with  a  subreport. 

(c)  Daily  Inpatient  Report.  T^s  report  provides  a  listing  of  the  current  inpatients,  and 
was  produced  each  morning  for  the  commander’s  information,  and  to  be  included 
m  tte  daily  Medical  Situation  Report.  Since  the  criteria  used  to  extract  the  report 
IS  Date  of  Discharge  is  Null,”  this  report  can  only  produce  information  on 
current  inpatients. 

(d)  Accident  Reports.  These  reports  were  produced  monthly  by  the  Safety  Officer 
^d  reported  to  the  Pleso  Camp  Commandant  (see  Tab  C4.5).  They  listed  the 
location  of  the  accidents  by  UN  Protected  Area  in  an  attempt  to  follow  trends  in 
the  entire  catchment  area  of  the  MASH.  A  summary  report  listing  monthly  totals 
by  category  is  also  available. 

(e)  Reports  for  Individual  Clinics.  The  breakdown  of  numbers  of  patients  seen  each 
month  by  disease  categories  can  be  limited  to  a  particular  clinic  and  a  particular 
time  frame. 

(f)  Other  reports.  As  the  data  entry  nears  completion,  and  after  action  reports  are 
being  written,  numerous  other  reports  have  been  developed,  looking  at  data  on 
medical  mpatients,  global  outpatients,  and  dental  patients. 

3.  Problems,  recommendations,  potential  improvments 
a.  Issue  —  Lack  of  a  networked  system 

(1)  Discussion.  This  has  b^n  the  main  limitation  to  the  development  of  this  database  and 
on  entering  data.  The  time  required  to  create  a  pseudo-network  using  floppy  disk-g 
severely  hampered  the  development  of  the  database  itself,  especially  when  added  to 
me  other  ‘housekeeping”  chores  such  as  backing  up,  repairing  and  compacting  the 
^tabase.  Twelve  to  sixteen  hours  were  spent  each  week  just  transferring  the  dfita 
from  one  machine  to  Mother.  This  was  done  by  the  SysOp  since  the  potential  for 
losing  data  OT  corrupting  the  database  through  the  slightest  misstep  in  this  process 
WM  ^eat.  Me  pseudo-network  was  also  inadequate  since  it  imposed  limitations  on 
which  machines  could  be  used  to  enter  each  type  of  data  and  limitations  on  which 
machine  could  be  used  to  edit  previously  entered  records  as  discussed  in  item 
2.b.(l)(c)  above. 


(2)  Recommendations 

(a)  Installation  of  a  networked  computer  system.  This  would  comprise  5  or  6 

workstations  and  a  file  server  on  an  Ethernet  network.  This  would  require  buying 
M  Eth^et  card  for  each  computer,  the  cabling  to  connect  them,  and  multiuser 
hcensed  copies  of  the  software  program.  These  requirements  have  already  been 
addressed  with  the  UNPROFOR  Infommtion  Technology  office,  (see  Tab  H  1.5). 
While  Aey  seemed  yeiy  positive  and  wilhng  to  provide  this  system  for  us,  along 
with  a  digital  tape  backup  system  and  training  for  the  persons  managing  the 
system,  they  have  not  yet  even  answered  the  memo  we  sent  them.  Follow  up  with 
them  is  needed.  The  points  of  contact  are  Mr.  Gary  Taylor,  Director  Mr  Jim 
Martn,  Computer  Network  Manager;  Mr.  Nelson  Gui,  Systems  Engineer  Thev 
are  located  at  UNPROFOR  HQ,  in  Zagreb,  P.O.  Box  870;  phone  385  41  180  01 1 
ext  2697. 
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(b)  If  this  office  fails  to  come  through  with  the  required  system,  it  is  strongly 

necessary  cards  and  software,  which  should  cost 
$2500  -  $3000  total.  The  cabling  can  be  provided  through  the  Harris 
Corpor^on,  if  needed,  as  &ey  upgrade  the  phone  system.  The  point  of  contact 

5?  Enyedi,  Business  Manager,  local  phone 

815071  (work),  650960  (home).  . 

b.  Lack  of  a  dedicated  staff 


(1)  The  Proble^  The  personnel  needs  for  this  project  were  not  understood  initially,  so 
me  required  people  were  not  assigned  and  trained  at  the  outset.  It  was  left  to  the 
SysOp  to  ca^  to  entire  load  of  coordinating  data  entry,  providing  the  human  conduit 
for  the  pseudo-ne^ork,  performmg  database  cleanup,  maintenance  and  backup, 
provimng  the  climcal  expertise  to  non-physicians  attempting  to  categorize  diagnoses, 
providing  traimng  and  troubleshooting  help  to  data  enterers,  developing  data  entry 
forms,  reports,  and  categorization  schemes,  and  incidentally  improving  the  datahase 
to  correct  its  we^esses  and  it  easier  to  use;  all  while  learning  the  software. 

u  u  j  u  from  the  adn^strative  staff  was  akin  to  begging  for  a  favor  since 
they  all  had  other  assigned  primary  duties,  and  much  of  the  work  was  best 
accomplished  after  normal  duty  hours,  which  made  such  requests  distinctly 
unpopular,  ^ce  ^ta  entry  was  the  first  priority,  the  housekeeping  chores  took 
precMence.Therefore,  the  manipulation  of  the  data  to  produce  reports  and  the  further 
development  of  the  database  itself  suffered  from  lack  of  attention. 

(2)  Recommendations 

(a)  Ite^cated  SysOp  to  perform  database  upkeep  and  maintenance,  and  management 
of  the  nemork  should  one  become  available.  A  second  person  should  be  trained 
m  these  skills  as  a  backup  since  there  must  be  someone  with  these  capabilities 
available  at  all  timesS. 

(b)  A  database  developer,  who  is  either  a  member  of  the  professional  staff,  or 
someone  who  can  work  closely  with  the  professional  staff,  to  manipulate  the  data 
tor  reports,  and  who  can  improve  the  database  in  the  ways  listed  in  item 
3.e.(6)below. 

(c)  Administrative  staff,  conversant  in  medical  terminology  to  coordinate  data  entry, 
and  ensure  accurate,  uniform  spellings  of  diagnoses  and  treatments. 

(d)  Administrative  staff  capable  of  coding  records  using  ICD-9  diagnostic  and 
procedure  codes. 

(e)  Professional  strff  input  for  corrections  of  diagnosis,  listing  of  procedures  done 
and  for  categorization  of  diseases. 


c.  Issue  —  Lack  of  a  central  point  for  all  patient  contacts. 

(1)  Discussion.  As  discussed  in  item  2.b.(l)(d)  above,  patients  enter  the  system  at  many 
different  dime  areas,  making  the  likelihood  of  duplicating  records  hi4  This  is 
especidly  trae  of  patients  who  are  logged  into  the  ER  with  a  problem  that  is 
i^ediately  referred  to  another  clinic,  such  as  Dental  or  Physical  Therapy  with  no 
diaposis  or  teatment  given  in  the  ER.  The  way  the  system  is  currently  St  up,  such  a 
I^tient  would  be  eiitered  twice  on  the  same  day  for  the  same  problem.  Another  form 
this  takes  is  the  patient  getting  entered  twice  under  different  names  or  UN  ID 
numbers  (see  discussion  under  item  2.b.(l)(e)  above).  We  have  attempted  to  address 
the  latter  problem  by  having  all  patients  reporting  to  Patient  Administotion  either 


8  In  fact,  the  TeleMed  system  will  also  require  technical  support  around  the  clock,  especially  when  the  MASH 
becomes  the  primary  consultation  node  for  the  US  troops  in  Macedonia.  In  that  case,  it  would  be  wise  to  have  a 
minimum  of  three  SysOps,  trained  in  both  systems;  the  third  to  provide  coverage  during  leaves. 
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before  or  after  their  visit  to  the  outpatient  clinic,  to  be  entered  into  the  database  and 
receive  a  Patient  Sequence  Number  by  which  their  demographic  data  is  linked  to  all 
other  tables  in  the  datable.  There  was  some  resistance  to  this  idea  from  the  providers 
^d  techmcians  in  the  clinics,  who  worried  that  their  patients  might  become  log- 
jammed  in  Patient  Administration,  but  tlus  has  not  proved  to  be  a  problem.  The  ER 
staff  prefers  to  see  and  evaluate  their  patients  first,  and  they  have  been  quite 
conscientious  in  directing  them  to  Patient  Administration  after  their  visit.  The 
problem  of  duplicate  visit  entries  has  been  addressed  by  periodically  sorting  the 
Outpatient  Visits  table  by  Patient  Sequence  Number  and  manually  inspecting  the  data 
for  duphcate  entries9.  This  is  becoming  a  bit  unwieldy  with  8000  records  to  look 
toough,  but  once  the  backlog  of  old  records  has  been  entered,  the  manual  search  can 
be  limited  by  date  of  visit. 

(2)  Recommendations 

(a)  Continue  the  current  practice  of  having  all  patients  report  to  Patient 
Admimstration  before  their  visit,  uidess  they  are  going  to  the  ER.  Ideally,  no 
patient  should  be  logged  into  a  clinic  until  he  has  a  Patient  Sequence  Number 
assigned  by  Patient  Administration. 

(b)  If  a  networked  system  becomes  available  then  the  Patient  Administration 
technicians  could  also  start  an  outpatient  visit  record  and  assign  a  visit  number  for 
a  particular  clinic.  The  techmcians  in  the  clinic  could  then  add  the  clinical  data  on 
the  visit  at  a  later  time.  It  is  important  to  have  the  clinic  technicians  enter  the 
c^nic^  dat^  since  they  have  some  knowledge  of  the  diagnoses  and  treatments 
that  the  Patient  Administration  technicians  lack. 

d.  Hardware  limitations 

(1)  The  Problem.  The  database  tends  to  run  too  slowly  on  the  386  machines  we  have 
available.  In  fact,  it  can  be  brought  to  a  virtual  standstill  if  the  100  Mb  hard  drive 
space  is  used  up  with  other  applications,  limiting  the  amount  available  to 
Windows’™  v^al  memory.  However,  since  computers  are  in  short  supply,  it  is 
impossible  to  limit  their  use  to  the  database  alone,  so  the  hard  drives  are  stuffed  with 
word  proc^sors,  graphics  programs,  utilities  and  a  moderate  number  of  the  smaller 
games  .  This  also  created  a  problem  with  access  time  to  the  computers,  since  there 
was  a  lot  of  backlogged  records  to  enter. 

(2)  Recommendations.  Unless  the  new  computers  being  brought  in  by  the  Navy  are  more 
powerfol  or  have  larger  hard  drives,  the  machines  used  for  the  database  must  be 
primary  dedicated  to  that  purpose.  The  addition  of  hne  word  processing  program, 
and  a  few  small  games  is  acceptable,  but  loading  several  word  processors,  a  graphics 
pro^^,  another  database  application,  and  a  large  graphics  oriented  game  onto  the 
hard  dnve  is  not. 

e.  Other  Improvements 

entry  forms,  particularly  for  tracking  accidents  and  injuries, 
flaggmg  follow-up  visits  and  admissions,  and  updating  A&D  forms  with  discharge 
diagnoses  and  non-operative  procedures. 

(2)  Categorizing  reportable  diseases  and  automating  the  reporting  process,  as  discussed 
m  item  2.b.(2)(b)5.  above.  r  & 


^  These  issues  are  discussed  in  detail  in  Tab  H2.  Database  Management. 

Allowing  editing  of  previously  entered  records. 

*  ^  We  felt  It  good  for  the  morale  of  the  technicians  doing  the  bulk  of  the  data  entry  to  leave  some  of  the  smaller 
games  on  the  machines.  The  informal  rule  was  equal  time  between  playing  games  and  entering  data. 
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(3)  S^g  conventions  for  diagnoses,  i.e.,  agreed  definition  of  FUO,  viral  syndrome, 
AGE,  infectious  dia^hea,  etc.  and  for  categorization,  so  that  immuniTatinns  and 
chrome  low  back  pain  are  categorized  as  Medicine,  while  an  acute  paraspnious 

muscle  spasm  from  hfting  a  heavy  object  is  an  Injury  (and  likely  an  industrial 
accident  as  well). 

(4)  Verifying  the  completion  of  the  creation  of  outpatient  records  for  direct  admissions  of 
pnor  deployments,  as  discussed  in  item  2.b.(  1  )(g)  above. 

(5)  Adding  Mental  Health  entries  to  the  database,  as  discussed  in  item  2.b.(l)(i)  above. 

(6)  Further  da^^e  development.  This  database  is  very  fragile,  since  few  protections 
have  been  built  in.  It  would  be  very  easy  for  an  untrained  operator  to  inadvertently 

corrupt  the  ^ta.  Making  the  database  buhetproof  would  have  taken  more 
time  toan  we  had,  and  m  some  cases  was  intentional  to  avoid  difficulties  in 
transferring  data  from  one  computer  to  another.  We  compensated  for  thi<;  bv 
pntinuously  reviewing  and  copecting  the  data  but  some  of  this  checking  remains 
incomplete,  smee  old  data  is  still  being  added. 

(a)  Protection  of  referential  integrity.  The  structure  of  the  database  is  denormalized  in 
several  ways,  which  have  not  been  corrected  due  to  lack  of  tirrift 

1.  Two  fields  in  the  A&D  records  are  duplicated  in  the  OUTPATIENT  DATA 
table.  These  are  Prmary  Disease  Category  and  Battle  vs.  Non-Battle  Injury 

A®  should  be  synchronized.  Once  entries  in  the 
UU 1  PATIENT  DATA  table  are  created  for  those  admissions  which  do  not 
have  one,  these  fields  should  be  deleted  from  the  A&D  DATA  table. 

The  records  of  admitted  patients  in  the  OUTPATIENT  DATA  table  need  to 
be  reviewed  to  ensure  that  the  ‘Admitted?’  check  box  is  checked,  especially 
for  those  records  from  the  prior  two  deployments. 

Identification  of  follow-up  visits.  This  is  a  crucial  flag  since  failure  to  check  it 
adds  another  count  to  the  incidence  of  an  illness,  making  the  reports  by 
^sease  categories  inaccurate.  It  is  often  missed  on  data  entry,  since  not  all  of 
the  \mtten  documents  have  this  information.  Standardized  data  entry  sheets 
shoitid  go  a  long  way  towards  correcting  this  problem,  but  this  should 
routinely  be  watched  for  and  corrected.  It  would  be  possible  to  create  a 

fu  ^  y^i^iation  to  prevent  this  from  occurring,  but  would  not  be  feasible  until 
the  database  is  put  on  a  network. 

^^^®utty  of  register  nurnber  from  A&D  Form  into  the  OR  DATA 
VT  u  ^  Form.  !^th  the  Patient  Sequence  Number  and  the  admission  Register 
Number  have  to  be  entered  manually  into  the  OR  DATA  ENTRY  Form,  with 
no  v^dation  that  these  two  numbers  are  related  to  each  other.  It  would 
require  some  exploration  of  the  database  capabilities  *2  to  be  able  to  lookup 
the  l^fed  ^  A&D  DATAtable,  while  avoiding  duplication  of 

(b)  Data  eni^  validation.  As  the  database  gets  larger,  visual  searches  of  all  of  the 
entoes  becomes  a  less  viable  option,  especially  in  the  PATIENT  DATA  table 
where  a  search  cannot  be  limited  to  current  entries.  However,  until  the  systern 
feoughr*^^  ^  network,  these  changes  should  be  made  slowly  and  with  great 

(c)  Addition  of  a  ‘Refereed’ field  to  the  OUTPATIENT  DATA  table  to  distinguish 
initial  visits  to  the  MASH  for  a  new  problem,  from  an  initial  visit  to  a  givM  clinic 


2. 


3. 


4. 


of  Patient  Sequence  Number  and  Date  of  Operation  would  have  to  be  used  to  search 
the  A&D  DATA  table  for  the  proper  Register  number. 
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for  a  problem  that  has  been  addressed  at  another  clinic  previously  (see  item 
2.b.(l)(d)2.  above). 

(d)  Automation  of  database  functions  for  end  users,  to  facilitate  navigating  around 
the  database,  performing  searches,  etc.  This  would  make  the  training  in  using  the 
database  easier  to  understand  which  would  allow  more  people  to  use  it.  It  would 
also  afford  the  endusers  the  ability  to  be  more  seif  sufficient,  while  keeping  them 
out  of  the  underlying  database  stracture,  where  they  might  break  something. 

4.  Significant  accomplishments 

a.  The  most  important  factor  contributing  to  the  success  of  this  project  was  the 
unambiguous  and  continuing  support  for  it  given  by  the  hospital  commander.  He  made  it 
clear,  by  his  words  and  actions,  that  he  considered  the  capturing  of  the  MASH  data  to  be 
one  of  the  highest  priorities  of  this  deployment.  Without  this  level  of  support,  this  project 
could  not  have  been  earned  out,  and  cannot  be  continued,  as  by  its  nature,  it  Hpmanfis  a 
continuous  high  level  of  attention  and  effort.  If  it  is  handled  in  a  perfunctory  manner,  it 
would  be  best  not  done  at  all  because  the  quality  of  the  data  would  rapidly  deteriorate 
into  meaninglessness. 

b.  Database  development 

(1)  Development  of  the  data  entry  forms  for  each  clinical  area:  Patient  Demographics, 
Admissions  and  Dispositions,  Operations,  and  Outpatient  Visits  for  the  Emergency 
Room,  Orthopedics,  Physical  Therapy,  and  Dental  Clinics.  Where  applicable,  these 
forms  include  pop-up  lists  of  common  diagnoses,  treatments,  religions,  nationalities, 
providers,  diagnostic  and  accident  categories,  etc. 

(2)  Development  of  categorization  schemes  and  entry  forms  for  diagnostic  categories, 
injury  types  and  causes,  accidents  and  causes,  and  breakdown  of  inpatient  diagnoses 
and  operations  by  (sub)specialty. 

(3)  Development  of  reports  on  daily  inpatient  census,  weekly  breakdown  of  diagnostic 
categories  for  US  patients  following  the  EU.COM  scheme,  monthly  breakdown  of 
diagnostic  categories  following  the  UNPROFOR  scheme,  and  monthly  analysis  of 
accidents  and  their  causes.  The  breakdown  by  diagnostic  categories  can  also  be 
limited  to  a  particular  clinic,  inpatients  alone^'-and  to  a  specified  time  frame.  Other 
reports  are  being  developed  as  the  need  arises. 

c.  Data  Entry.  All  available  records  of  patient  contacts  with  the  MASH  from  Nov  92 
through  the  present  have  been  entered.  The  numbers  of  records  entered  are  as  follows: 


Patient  Demographic  Data  4,865 

Outpatient  Visits  9,690 

Admissions  and  Dispositions  978 

Operations  and  Anesthetic  Episodes  525 

Total  16,058 


5.  Interface  with  the  UN. 

a.  Dealing  with  foreign  names.  The  biggest  impact  that  operating  in  a  multinational 
enviroriment  has  had  on  data  entry  is  the  difficulty  in  dealing  with  names  that  are  not 
immediately  recognizable  ^  such.  This  has  led  to  numerous  duplications  of  entries  into 
the  Patient  Data  table,  and  is  the  strongest  argument  for  having  all  patients  report  to  the 
Patient  Administration  section  to  be  entered  into  the  database  directly. 
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(1)  In  m^y  cases  it  is  nearly  impossible  to  determine  what  is  what  we  would  call  a  ‘first 
name  from  what  we  would  call  a  ‘last  name’,  especially  in  those  cultures  where  a 
pereon  is  usu^y  addressed  by  his  given  name  rather  than  by  his  family  name. 

^  written  on  their  UN  ID  card  helps,  but  this  is  often  contradicted  by 
what  they  c^Aemselves  and  by  what  their  physicians  write  on  their  transfer 
siminanes.  This  leads  to  the  duplication  of  entries  that  is  the  hardest  to  detect 
visually  m  the  database. 

(2)  The  combination  of  foreign  spellings,  often  using  letter  combinations  not  found  in 
English,  with  the  yaganes  of  interpreting  someone  else’s  handwriting,  have  led  to 
certam  patients  bemg  entered  into  the  database  4-6  times  each.  The  patient 
Viirtagen  was  entered  as  Virtagen,  Vurtagen,  Virtgen,  etci3  These  duplications  can 
usu^y  be  fou^  by  sortmg  the  Patient  Data  table  by  last  name  and  looking  though  all 
of  the  entnes.  One  advantage  to  having  such  unusual  names,  is  that  one  can  also  pick 
up  duphcauons  by  sortmg  the  table  by  first  names. 

b.  Lack  of  uniformity  of  UN  ID  numbers  *4.  These  numbers  are  generally  comprised  of  2  or 
3  letters  followed  by  5  or  6  digits.  However,  the  order  of  letters  and  numbers  might  be 
reversed,  or  there  may  be  no  letters  at  all  and  only  3  digits.  Some  of  our  patients,  like  the 
refugees,  had  no  ID  numbere  at  all,  and,  as  mentioned  earlier,  the  members  of  the  US 
conrtngent  had  both  their  UN  and  social  security  numbers.  All  of  this  made  automated 
validation  of  data  entry  for  this  important  field  next  to  impossible.  This  necessitated 
developing  stiict  convenUons  to  be  used  when  entering  these  numbers,  which  are  listed  in 
Tab  H.2.  Datatoe  M^agement.  A  new  twist  has  just  arisen,  in  that  the  UN  has  decided 
to  change  *e  JD  ^mbere  of  aU  independent  contractor  staff  to  distinguish  them  from 
regum  UN  staff.  This  change  is  expected  to  be  completed  by  the  end  of  March.  We  are 
already  seeing  paUents  who  have  been  entered  in  the  past  under  their  old  number,  now 
retunung  for  medical  care  under  their  new  number. 

6.  Moving  into  Phase  n 

a.  In  the  first  phase  of  this  project,  the  main  concern  was  entering  and  validating  the  vast 
amount  of  data,  and  Ae  bulk  of  the  energy,  thought,  and  resources  was  devoted  to  that 
gom  as  the  content  of  this  document  illustrates.  However,  it  is  very  easy  to  get  caught  up 
m  the  fimc^  activiUes  of  getting  Ae  data  in  and  lose  sight  of  the  reason  th£  we  do  this 
at  all,  which  is  to  get  the  information  out. 

b. 


♦u..  .a..*..  *1.  ..  *1. - .  I  uiiui  aiA  wccjts  aiicr  siarung 

to  enter  the  date  that  other  quesUons  started  to  arise  that  couldn’t  be  answered  by  the  data 

we  had  entered  or  by  the  way  we  had  formatted  it.  In  order  to  produce  information  on  the 
Mtepnes  of  illnesses  seen,  or  more  especially  identifying  accidents  and  their  causes,  we 
had  to  modify  bo^  the  structure  of  the  database  and  the  information  we  put  down  in  the 
wrmen  reco^.  Then  we  had  to  go  back  to  the  reco  rds  we  had  already  entered,  and  try  to 
find  the  addiuonal  infoimauon.  Aside  from  being  a  lot  of  extra  work,  the  problem  widi 
doing  this  IS  that  often  the  information  is  not  there.  It  was  not  written  down  because 
nobody  knew  that  it  was  needed. 

The  point  of  this  M  harangue,  is  to  stress  the  need  to  find  out  what  the  questions  are 
now,  not  when  it  s  time  for  people  to  write  their  after  action  reports.  Since  this  database 
was  conceived  as  a  climcal  ftinction  more  than  an  administrative  one,  it  is  crucial  to 


13  ^course,  in  this  case  ttere  had  to  be  a  concomitant  error  in  entering  the  UN  ID  number  as  well  since  duplicate 

ID  s  are  not  accept^.  This  was  one  of  the  cases  that  taught  us  the  need  to  stick  to  very  precise  conventions  when 
entenng  these  numbers. 

The  term  UN  ID  is  used  loosely  here,  as  there  were  many  members  of  other  non-governmental  organizations,  as 
well  as  civilian  employees,  each  with  their  own  ID  cards  and  numbering  schemes. 
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involve  the  professional  and  nursing  staff  in  determining  what  the  questions  will  be 
before  starting  to  enter  all  of  the  records^^.  They  can  be  reassured  that  they  don’t  need  to 
be  computer  literate  in  order  to  take  part  in  this,  but  then  again,  the  people  with  the 
questions  are  the  best  ones  to  get  to  categorize  the  data  to  answer  those  questions. 


We  have  refrained  from  celebrating  with  a  bonfire  of  all  the  old  records,  in  case  there  was  something  else  one 
might  want  to  glean  from  them,  although  we  have  picked  those  bones  pretty  clean. 
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[Zagreb  Letterhead] 


FROM:  Maj  Janet  T,  Martino 
SUBJ:  Tab  H2.  Database  Management 

TO:  After  Action  Report  and  Transition  Document,  21  Sept  93  -  17  Mar  94 


13  Mar  94 


1.  Windows™  operating  system  shell  must  be  running  in  order  to 

use  Microsoft  ACCESS™.  Once  m  Windows™  go  to  the  Program  Manager  AppUcations 
window.  If  the  Applications  window  is  not  showing,  you  can  open  it  by  selecting  it  in  the 
listing  un^r  the  Window  menu.  Once  in  the  Applications  window,  find  the  icon  for  the 
database.  Double  dic^g  this  icon  will  open  the  database.  The  name  of  the  icon  will  vary 
depending  upon  which  computer  you  are  on.:  ^ 


“A«&D  Database”  on  the  Patient  Administration  and  SysOp’s  computers. 
“Patient  Database”  on  the  ER  computer. 

“A&D  /  OR  Database”  on  the  OR  computer. 


Data  Entiy.  All  ^ta  entry  is  done  from  forms,  not  tables.  When  the  database  is  first  opened, 
the  defoult  is  to  show  the  hsting  of  tables.  The  data  enterers  must  be  trained  to  find  the  proper 
form.  Only  the  SysOp  should  ever  need  to  use  the  tables. 


a.  Conventions.  The  most  important  factor  in  avoiding  duplications  and  other  errors  is 
consistency  in  data  entry.  These  are  the  conventions  we  entered  the  by: 

(1)  Names.  As  discussed  in  item  5.a.  in  Tab  H.l.  there  were  two  major  problems  in 
dealing  with  foreign  names,  distinguishing  ‘first’  and  ‘last’  names,  and  getting  the 
correct  spelling.  Both  of  these  problems  were  addressed  by  having  a  small  cadre  of 
people  m  Patient  Administration  do  all  of  the  entry  into  the  Patient  Data  table.  These 
tectaicians  understood  the  importance  of  getting  this  right,  and  were  trained  to  do 
multiple  searches  in  the  LName  and  FName  fields  with  a  variety  of  likely  spellings, 
as  well  as  searching  on  Social  Security  or  ID  numbers  (see  item  4.a.  below).  This 
actually  became  easier  as  time  went  by  and  the  old  mistakes  corrected,  since  fewer 
mistakes  were  being  made  on  entry. 

(2)  SSN/ ID  Numbers 

(a)  Letters  must  be  separated  from  the  digits  by  one  space,  regardless  of  where  thev 

occur.  •’ 

(b)  All  US  patients  are  entered  using  their  SSN,  rather  than  their  UN  ID’s,  to 
facilitate  integration  with  their  medical  records. 

(c)  All  SSN’s  are  entered  in  the  format:  ###  ff#  mill,  using  a  as  a  divider. 

(d)  Children  or  spouses  of  embassy  workers  without  their  own  number,  use  their 
sponsor  s  number  with  the  appropriate  family  member  code  preceding  it  and 
separated  by  a  space  .  Family  member  codes  are  not  used  otherwise. 

(3)  Dates.  These  are  usually  entered  in  short  form  as  mm/dd/yy.  ACCESS  will  accept  anv 
standard  date  format,  such  as  23  Mar  94,  and  convert  it  to  the  short  form  correctly 
However,  if  the  date  is  entered  in  the  short  European  format  of  dd/mm/yy,  errors  will 


(4)  Inpatient  Register  Numbers.  There  was  no  convention  established  between  the  212th 
and  502nd  contingents  with  respect  to  register  numbers  for  inpatient  records.  When 


'  Family  member  codes:  20  for  the  sponsor,  30  for  the  spouse,  01  for  the  firstborn  child,  02  for  the  second,  etc. 
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we  to  input  these,  we  found  that  there  were  duplications  of  this  number,  so  we 

created  the  following  convention  and  annotated  the  paper  files  accordingly. 

(a)  For  records  from  the  212th  MASH,  20,000  was  added  to  the  existing  register 

numben  ® 

(b)  For  records  from  the  502nd  MASH,  10,000  was  added  to  the  existing  register 

number.  ® 

(c)  For  the  48th  ATH,  register  numbers  start  at  31001  and  run  sequentially  upwards^. 

(d)  "^e  records  were  assi^ed  these  prefixes  based  upon  the  contingent  commanding 
the  hospi^  on  the  patient’s  date  of  admission.  The  change-over  from  the  212th  to 
the  502nd  occurred  on  28  Apr  93;  from  the  502nd  to  the  48th  ATH  on  5  Oct  94 
and  from  7  Mar  94. 

(e)  It  would  be  logical  to  start  numbering  the  records  for  the  Navy  at  40xxx. 

(5)  Abbreviations.  The  rale  is  that  the  only  abbreviations  allowed  are  those  recognizable 

by  most  of  the  people  using  the  database.  Thus,  diagnoses  such  as  URI,  and  AGE  are 
allowed,  while  ETD  (eustachian  tube  dysfunction)  is  not.  Likewise  for  treatments 
where  standard  drug  prescribing  abbrpiations  are  allowed.  This  is  one  of  the 
adv^tages  of  having  the  techmcians  in  a  given  clinic  enter  the  data  for  their  own 
clinic  they  know  better  than  most  what  the  providers  they  work  with  are  talking 

about.  In  specialty  ^eas,  with  a  more  limited  set  of  diagnoses  and  treatments,  the  job 
of  spelling  out  specialty  terminology  was  made  easier  by  using  pop-up  menus.^ 

(6)  Follow-up  Visits.  The  Follow-up  field  asks  the  question  with  respect  to  each 
individual  outpatient  clinic.  Therefore,  a  patient  can  be  seen  for  the  same  ‘new’ 
problem  in  more  than  one  clinic,  such  as  the  ER  and  Physical  Therapy  (see  discussion 
m  Tab  H.l  Database  Development,  item  2.b.(l)(d)2 

b.  Use  of  Pop-up  Menus.  Fields  with  downgoing  arrows  next  to  them  have  pop-up  (or 
(fropdown)  menus.  Although  you  can  type  in  one  of  the  choices,  or  type  something  else 
that  IS  not  on  the  menu,  it  is  best  to  use  the  menu,  even  if  it  slows  a  fast  typist  down. 

Using  the  menus  prevents  typographical  errors,  and  ensures  that  the  entry  makes  sense 
rather  than  just  a  synonym  for  another  choice.  If  new  items  need  to  be  entered  into  the 

menu,  they  should  be  brought  to  the  SysOp’s  attention  so  that  they  may  be  entered  into 
the  menu. 

c.  Mandatory  Fields.^  In  order  to  maintain  referential  integrity,  the  database  will  not  let  a 
record  be  entered  if  certain  crucial  data  for  the  record,  such  as  Patient  Sequence  Number 
IS  not  entered.  If  you  try  to  leave  that  record,  a  warning  dialog  appears  saying,  “The  join 
IS  broken  by  value(s)  in  fields  ...  (usually  Patient  Sequence  Number)”.  This  is  not  a 
problem  when  you  have  just  forgotten  to  enter  that  piece  of  data;  once  it’s  entered,  you 
can  proceed  normally.  However,  often  someone  will  inadvertently  activate  a  blank  record 
by  clicking  in  it  somewhere,  and  then  find  that  they  can’t  leave  the  record  because  they 
haven  t  entered  a  patient  number.  The  database  gets  quite  insistent  about  this,  not  letting 
you  do  anything  else  until  it  gets  the  piece  of  data  it  wants.  The  only  way  to  get  out  of 
this  is  to  close  the  entire  form  window.  The  same  warning  will  appear,  but  now  if  you 
click  the  ‘OK’  button,  another  warning  about  will  appear  saying,  “The  record  being 
edited  can  t  be  saved.  If  you  close  the  form,  the  changes  you’ve  made  to  the  record  will 
be  lost.  Close  anyway?”.  Click  on  the  ‘OK’  button.  The  record  will  be  lost,  but  this  is  all 
nght,  as  It  IS  not  wanted  anyway.  Now  the  form  can  be  opened  again,  as  usual. 


^There  are  some  48th  ATH  register  numbers  in  the  30xxx  range.  These  are  A&D  records  created  for  same  day 
surgical  procedures. 
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d.  Patient  Data.  Use  the  Patient  Data  Entry  form.  Tab  H  2. 1 . 

(1)  During  normal  duty  hours,  patients  are  sent  to  Patient  Administration  Section  from 

cu  u  patient  is  asked  whether  he  has  ever  been  seen  anywhere  in  the 
MASH  before.  If  the  answer  is  no,  he  can  be  entered  directly  and  assigned  a  sequence 
number  without  extensive  searching.  If  he  has  been  seen  before,  the  Patient  Data  table 
IS  s^ched,  usually  on  the  SSN  or  ID  number.  When  the  record  is  found  the  is 

verified,  and  the  Patient  Sequence  Number  written  on  the  form  used  by  the  clinc  to 
doc^ent  the  visit  For  patients  s^n  after  duty  hours  in  the  ER,  the  Standard  Form 
^8  s  are  brought  to  Patient  Adn^stration  for  patient  data  entry  the  next  morning, 

On  weekends,  the  Patient  Administration  technician  on  call  will  enter  all  of  the 
patients  seen  through  Saturday  into  die  database  by  Sunday  morning.  This  allows  the 
climc  data  to  be  entered  on  Sunday  in  order  to  be  completed  for  the  weekly  report 
due  the  following  week  (see  item  5.c.  below).  ’ 

(2)  The  558 ’s  are  sorted  into  two  piles,  one  for  patients  never  seen  at  the  MASH  before 

onefor  patients  previously  entered.  The  second  pile  is  returned  to  the  ER  at  the 
end  of  me  day,  m  the  clinic  record  can  be  entered  during  the  night  shift  (see  section 

l.e.(l)  below).  The  pile  of  new  patients’  records  cannot  be  entered  until  the  Patient 
Data  table  is  transferred  from  the  computer  in  the  Patient  Administration  Section  to 
the  one  m  the  ER.  This  is  done  by  the  SysOp  who  brings  those  558’ s  to  the  ER  at  the 
same  time. 

(3)  When  a  new  patient  data  record  is  to  be  entered,  the  technician  goes  to  the  last  record 
to  determine  the  highest  sequence  number.  He  then  goes  to  the  next,  blank  record, 
and  assigns  the  next  highest  sequence  number.  As  a  check,  the  record  number  and  the 
sequence  number  should  matcM 

(4)  The  rest  of  the  data  should  be  entered  as  indicated. 

(5)  At  the  end  of  a  data  entry  session,  or  after  a  significant  amount  of  data  has  been 
entered  go  to  the  ^tabase  listing  of  macros,  choose  the  ‘Trans  Tables  to  XLS’  macro 
and  click  the  Run  button.  This  will  create  a  backup  copy  of  your  work. 

e.  Outpatients. 

(1)  Emergency  Roorn^.  Use  the  Outpatient  Visits-Data  Entry  form.  Tab  H  2.2. 

(a)  Patient  is  signed  into  the  ER  on  a  Standard  Form  558,  which  includes! 

1.  The  patient’s  demographic  data. 

2.  ER  data,  such  as  whether  the  patient  smokes,  and  the  status  of  his 
immunizations. 

3.  Whether  this  is  a  follow-up  visit  for  the  same  problem  as  a  previous  visit. 

4.  If^s  is  an  accident,  the  circumstances  surrounding  it  -  the  how,  when  and 
where  of  the  occurrence. 

provider  sees  the  patient  and  documents  the  diagnosis  and  treatment  on  the 
SF  558. 

(c)  The  pEtient  is  sent  to  Pntient  Administration  for  a  Patient  Sequence  Number, 
which  is  written  in  on  the  bottom  of  the  558.  The  558 ’s  for  patients  previously 
seen  at  the  MASH  are  returned  to  the  ER  at  the  end  of  each  day,  to  allow  entry  of 
the  visit  data  to  be  done  on  the  night  shift.  Every  second  or  third  night,  depending 
upon  how  many  records  have  accumulated  and  whether  it  is  the  end  of  the  week 


^This  is  the  only  table  in  the  database  where  this  is  so,  since  there  should  always  be  a  one  to  one  relationship 
between  the  number  of  patients  and  the  patient’s  number. 

5  This  would  be  the  first  function  for  which  a  paper  data  collection  form  should  be  created. 
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(running  Sun  -  Sat),  the  SysOp  transfers  the  Patient  Data  table  to  the  ER 
computer  and  brings  the  558’s  of  the  new  patients  to  the  HI  for  data  entry. 

(d)  C^en  &e  Outpatient  Visits  Data  Entry  form,  go  to  the  last  record,  and  Tnalfpi  note 
of  the  highest  visit  number^.  T^e  next  visit  number  should  be  one  higher"^.  Go  a 
blank  record  and  enter  the  Patient  Sequence  Number  in  the  appropriate  box.  On 
tabbing  out  of  this  box,  the  patient’s  name  and  demographic  data  should  appear  in 
the  grey  rectangle;  check  to  make  sure  this  is  correct.  Assign  the  next  visit  ID 
number.  Enter  the  remainder  of  the  data  as  indicated. 

(e)  Use  the  Chief  Complaint  box  only  when  it  adds  information  not  entered 
elsewhere.  There  is  no  need  to  write  “I  have  a  headache”  there,  when  the 
diagnosis  is  Headache.  However,  it  is  important  to  use  this  box  to  state  the 
circumstances  leading  to  an  accident,  especially  whether  it  occurred  at  work  or 
during  sports,  whether  it  was  ^cohol  related  and/or  an  MVA;  or  whether  it  was  a 
battle  injury,  and  if  so,  what  kind.  This  should  be  typed  in  even  though  you 
choose  the  same  information  from  the  Accident  Cat  pop-up  menu. 

(f)  Other  very  important  boxes  to  check: 

1.  Date  of  visit 

2.  Time  of  visit  (even  an  approximation  is  better  than  nothing) 

3.  Follow-up  Visit? 

4.  Admitted? 

(g)  When  you  are  done,  be  sure  to  mark  the  558  as  having  been  entered.  (A  lot  of 
time  is  wasted  entering  visits  twice,  then  looking  for  duplicate  entries  and  deleting 
them).  Then  file  the  558  in  the  accordion  file  in  the  ErC 

(h)  At  the  end  of  a  data  entry  session,  or  after  a  significant  amount  of  data  has  been 
entered,  go  to  the  database  listing  of  macros,  choose  the  ‘Trans  Tables  to  XLS’ 
macro  and  click  the  ‘Run’  button.  This  will  create  a  backup  copy  of  your  work. 

(2)  Orthopedics,  Physical  Therapy,  and  Dental  Clinics.  Use  the  appropriate  former 

Ortho  Cline  Visits  Entry,  Tab  H  2.3. 

PT  Cline  Visits  Entry,  Tab  H  2.4. 

Dental  Cline  Visits  Entry,  Tab  H  2.5. 

(a)  The  system  is  essentially  the  same  as  that  of  the  ER,  although  these  clinics  tend  to 
send  the  patients  to  the  Patient  Administration  section  with  the  clinic  form  to  get  a 
sequence  number  before  seeing  the  patient.  This  allows  them  to  keep  the  written 
record  in  their  clinics  for  later  entry  of  the  visit  data.  Initially,  they  hart  a  large 
backlog  of  data  to  enter  and  so  were  assigned  another  computer  to  use.  Since  that 
backlog  is  caught  up,  we  are  having  them  do  their  data  entry  on  the  computer  in 
Patient  Admnistration  in  the  late  afternoon  and  evenings,  when  there  is  less 
chance  of  time  conflicts.  The  patient  demographic  data  is  entered  on  that 


^  For  all  copies  of  the  database,  this  form  is  automatically  sorted  in  order  of  visit  number,  so  that  the  last  record  will 
be  the  highest.  In  addition,  on  the  ER  copy,  only  the  records  below  10,000  are  shown,  so  the  ER  technicians  are 
not  confused  by  the  other  clinic  entries  which  use  higher  visit  numbers. 

’’  In  fact,  this  is  not  crucial,  as  long  as  it  is  below  10,000  and  not  a  duplicate.  However,  the  number  assigned  should 
not  be  random,  so  that  one  has  some  idea  where  the  unused  numbers  lie. 

8  At  the  end  of  the  month  the  accordion  file  is  brought  to  Patient  Administration  to  be  available  for  reference  during 
categorization.  The  file  from  the  month  preceding  the  just  ended  month  is  emptied,  the  558’s  filed  away,  and  the 
accordion  file  recycled  for  the  new  month.. 

^  All  of  these  forms  enter  data  into  the  Outpatient  Data  table.  Different  entry  forms  are  used  to  allow  customized 
pop-up  menus  for  diagnoses  and  treatments.  The  Qinic  field  also  defaults  to  the  clinic  for  which  the  form  was 
created. 
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computer  to  start  with,  so  they  do  not  have  to  wait  for  the  PATIENT  DATA  table 
to  be  transferred  to  another  site.  However  there  is  a  caveat  to  using  a  second  or 
third  computer  to  enter  data  into  the  Outpatient  Visits  table.  Since  data  is  being 
^t^red  into  the  same  table  by  several  non-networked  machines,  it  is  crucial  that 
the  Visit p  Numbers  assigned  to  each  entry  are  not  duplicated,  as  this  Visit  ID 
number  is  the  primary  key  to  that  table.  If  this  is  not  adhered  to,  data  will  be  lost 
whent^  two  copies  of  this  table  are  combined.  To  get  around  this  problem,  only 
Visit  ID  Numbers  below  10,000  are  assigned  using  the  ER  computer.  Numbers 
front  10,000  to  14,999  are  assigned  only  from  the  computer  being  used  for 
backlogged  records,  and  15,000  and  above  from  the  computer  in  Patient 
Administration. 

(b)  Open  the  form  for  the  clinic,  go  to  the  last  record,  and  make  note  of  the  highest 
visit  number.  It  should  be  greater  than  15,000.  The  new  visit  number  should  be 
one  higher.  Go  to  a  blank  record  and  enter  the  Patient  Sequence  Number  in  the 
appropriate  box.  On  tabbing  out  of  this  box,  the  patient’s  name  and  demographic 
data  should  appear  in  the  grey  rectangle;  check  to  make  sure  this  is  coirect. 

Assign  the  next  Visit  ID  Number.  Enter  the  remainder  of  the  data  as  indicated. 

(c)  Use  the  Chief  Complaint  box  only  when  it  adds  information  not  entered 
elsewhere.  It  is  important  to  use  this  box  to  state  the  circumstances  leading  to  an 
accident,  especially  whether  it  occurred  at  work  or  during  sports,  whether  it  was 
alcohol  related  and/or  an  MVA;  or  whether  it  was  a  battle  injury,  and  if  so,  what 
land.  TWs  should  be  typed  in  even  though  you  choose  the  same  information  from 
the  Accident  Cat  pop-up  menu.  This  information  should  be  entered  for  each 
follow-up  visit  as  well. 

(d)  Other  very  important  boxes  to  check: 

1.  Date  of  visit 

2.  Follow-up  Visit? 

3.  Admitted? 

(e)  At  the  end  of  a  data  entry  session,  or  after  a  significant  amount  of  data  has  been 
entered,  go  to  the  database  listing  of  macros,  choose  the  Trans  Tables  to  XLS’ 
macro  and  click  the  Run  button.  This  will  create  a  backup  copy  of  your  work. 

f.  Inpatients.  Use  the  A&D  form.  Tab  H  2.6 

(1)  This  form  is  filled  out  by  the  Patient  Administration  technicians  when  the  patient  is 
admitted.  If  pEtient  has  never  been  seen  in  the  MASH  before,  they  first  enter  him 
into  the  PATIENT  DATA  table  and  assign  a  Patient  Sequence  Number.  This  is  then 
entered  into  the  appropriate  box  on  the  A&D  Form.  On  tabbing  out  of  this  box,  the 
patient  s  name  and  demographic  data  should  appear  in  the  grey  rectangle;  check  to 
make  sure  this  is  correct.  A  Register  Number  is  assigned,  in  the  appropriate  range 
(see  Item  2.a.(4)  above),  one  higher  than  that  of  the  last  admission. 

(2)  Fill  in  the  remainder  of  the  data  as  indicated.  The  adimtting  diagnosis  should  be 
entered.  Tlus  can  be  updated  to  the  discharge  diagnosis  when  the  patient  is  discharged 
or  at  any  time  a  more  definitive  diagnosis  is  reached. 

(3)  Oil  discharge,  the  patient  s  record  can  be  found  by  searching  on  the  register  number 
and  updated  with  the  discharge  date,  diagnosis,  and  the  procedures  performed. 

(4)  At  the  end  of  a  data  entry  session,  or  after  a  significant  amount  of  data  has  been 
entered,  go  to  the  database  listing  of  macros,  choose  the  Trans  Tables  to  XLS’  macro 
and  click  the  Run  button.  This  will  create  a  backup  copy  of  your  work. 
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g.  Operations.  Use  the  OR  Data  Entiy  form.  Tab  H  2.7. 


(1)  This  form  is  generally  filled  out  by  one  of  the  OR  nurses.  Because  both  the  Patient 
Sequence  Number  and  the  Register  Number  must  be  entered,  the  OR  data  entry 
caraot  be  done  until  both  the  PATIENT  DATA  and  A&D  DATA  tables  have  been 
updated  oii  the  OR  computer.  Since  the  numbers  are  relatively  small,  they  can  be 
looked  up  by  the  OR  nurse  when  entering  the  records.  Another  option  is  to  give  the 
operation  sh^ts  to  the  Patient  Administration  technicians  to  do  the  searches  and 
annotate  the  Patient  Sequence  Number  and  the  Register  Number. 


(2)  Open  &e  OR  l^a  Entry  form,  go  to  the  last  record,  and  make  note  of  the  highest  OR 
r'.a^  Ni^ber.  ^e  next  Case  Number  is  assigned  automatically  and  should  be  one 
higher.  Go  to  a  blank  record  and  enter  the  Patient  Sequence  Number  in  the 

^  tabbing  out  of  this  box,  the  patient’s  name  and  demographic 
should  a^ear  in  Ae^^y  rectangle;  check  to  make  sure  this  is  correct.  Type  in  the 
Register  Number  .  The  next  OR  Case  Number  will  be  generated  automatically,  via  a 
counter  field.  Enter  the  remainder  of  the  data  as  indicated. 


(3)  Eai^  ^mprises  one  anesthetic  episode,  regardless  of  how  many  procedures  are 
performed.  For  each  procedure,  there  is  a  Procedure  Type  field,  that  is  based  upon  the 
ty^  of  sitfgei^h^r^edure  was,  regardless  of  the  specialty  of  the  surgeon  who 
perfomed  It.  The  Dx  Codes  Md  Procedure  Code  fields  are  for  ICD-9  codes.  Each 
procedure  is  attributed  to  a  primary  surgeon,  who  is  choosen  from  a  drop-down  menu 
which  li^s  the  surgeons  in  order  of  the  frequency  of  their  operations:  Orthopedics, 
General  Surgery,  and  Oral  Surgery. 


(4)  The  Room  field  is  for  the  location  of  the  procedure,  either  ‘1’  or  ‘2’  for  the  operating 

rooms,  W  for  anesthetic  procedures  done  on  the  ward,  and  ‘ER’  for  the  emergency 
room.  ®  ^ 


(5)  The  Urgency  option  box  allows  only  one  of  the  choices  to  be  selected.  The  choices 
are  Emergent,  Return  Post  Emergency,  and  Planned. 

(6)  Likewise,  the  ^esthetic  option  box  allows  only  one  of  the  choices.  If  a  procedure  is 
started  with  a  lower  level  of  anesthesia,  and  the  anesthesia  is  changed,  the  higher 
level  of  anesthesia  is  choosen. 


(7)  There  are  several  fields  for  the  timing  of  the  procedures.  These  are  agreed  upon  by 
the  Circulator  and  Anesthesia.  f  j 

(a)  ^esth  Start  and  End  Time:  Determined  by  the  time  the  patient  enters  to  OR  until 
the  time  he  leaves. 


(b)  Surgety  Start  and  End  Time:  Measured  from  the  time  of  incision  until  the  time  of 
wound  dressing. 

(c)  Nursing  Start  and  End  Time:  The  time  for  setup  and  cleanup  of  the  procedure. 

(8)  The  OR  Staff  is  chosen  from  drop-down  menus.  The  choices  on  the  menus  can  be 

current  staff.  Currently,  the  Anesthetists  fields  list  only  the 
Anesthesia  staff.  The  Surgical  Assist’s  fields  list  ^1  of  the  physicians  since  any  of 

f  j  Circulators  and  Scrabbed  sets  of  fields  list  all 

of  the  OR  nurses  Md  technicians.  Since  the  nurses  tend  to  circulate,  they  are  listed 
first  m  the  menus  for  those  fields.  Technicians  are  listed  first  in  the  Scrubbed  fields 
since  they  are  most  often  scrubbed. 


'0  Some  of  the  OR  records  do  not  have  a  Register  Number  since  the  patient  was  never  admitted  for  what  was  an 
outpatient  procedure.  When  this  problem  was  discovered,  we  started  to  admit  them  as  a  same  day  surgery  but 

some  of  the  earlier  cases  may  have  slipped  through. 
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(9)  At  the  end  of  a  data  entry  session,  or  after  a  significant  amount  of  Hata  has  been 
entered  go  to  ±e  database  listing  of  macros,  choose  the  ‘Trans  Tables  to  XLS’  macro 
and  click  the  Run  button.  This  will  create  a  backup  copy  of  your  work. 

Cat^orization.  Once  the  records  have  been  entered  and  the  tables  copied  back  to  the 
bysOp  s  coinputer,  the  various  categories  can  be  assigned.  This  can  only  be  done  at  this 
computer,  since  once  the  records  have  be  copied  to  it,  any  changes  to  those  records  on 
another  computer  will  be  lost.  The  only  exception  to  this  is  the  A&D  DATA  table  which 
must  be  edited  on  the  Patient  Administration  computer.  Because  a  certain  level  of  clinical 
expernse  is  required  to  assign  the  categories  appropriately,  this  should  not  be  left  to  the 
teclmiciMS.  All  of  the  categories  should  be  assigned  by  either  the  professional  or  the  nursing 
«mf,  with  the  exception  oftoe  accident  categories,  which  were  assigned  by  the  safety  officer. 
Of  course,  assignment  of  ICD-9  codes  requires  someone  trained  or  trainable  in  coding**.  One 
caveat  when  there  ^  several  people  assigning  categories  —  be  sure  that  they  all  agree  on 
wkch  dia^oses  belong  to  which  category.  For  example,  the  EUCOM  scheme  considers 
otitis  media  to  belong  to  the  Respiratory  category,  but  we  have  decided  that  otitis  externa 
telongs  to  the  Medical  category.  We  do  not  consider  Battle  Injuries  to  be  Accidents,  but  all 
Non-Battle  Injunes  are,  unless  they  are  self-inflicted*^ 

a.  Diagn^c  ^d  Accident  Categorization.  Use  the  Diagnostic  Category-General  Entry 

rorm.  This  form  is  a  limited  version  of  the  four  outpatient  clinics’  forms,  containin*^  onlv 
the  information  needed  to  assign  the  categories.  ^ 

b.  Primary  Diagnostic  Category  Code.  Use  the  A&D  Form.  This  field  is  a  duplication  of  the 
Diagnostic  category  codes  used  for  Ae  outpatient  visits  records.  It  will  eventually  be 
deleted  when  all  of  the  admitted  patients  have  entries  made  in  the  outpatient  table. 


4. 


c. 


(Individual)  Diagnostic  Category.  Use  the  A&D  Form.  This  categorization  is  based  upon 
organ  syst^  involvement  or  by  (sub)specialty  category.  This  is  independent  of  the 
specialty  of  the  primary  physician. 

d  Surgicd  Procedure  Type.  Use  the  OR  Data  Entry  Form.  These  categories  are  applied  to 
surgicm  procedures  performed  in  the  OR,  to  break  these  down  according  to  sur<^ical 
proce^^  t*ody  region  regardless  of  the  specialty  of  the  surgeon  performing  the 

^  forsmgkd*^ocedu^^^*^^  inpatient  diagnoses,  and  the  OR  Data  Entry  Form 

Ver^cation  arid  Conection  of  Entries.  In  the  absence  of  corhplete  automatic  data  entry 
validation,  verification  of  entries  must  be  done  by  repeated  visual  inspection  of  the  data  The 

duplication  of  records  in  the  PATIENT  DATA  and 
DU  iFAilEOT  VISITS  tables,  and  omission  of  entries  in  the  OUTPATIENT  VISITS  table 
tor  patier^  admitted  directly  from  outpatient  clinics.  These  errors  were  found  by  using  filters 
to  order  the  records  in  a  way  that  would  make  the  errors  obvious.  This  was  done  using  the 
pertinent  forms,  usually  in  the  datasheet  view.  ® 

a.  Patient  Data  Entry  form. 

(1)  Sort  by  each  of  the  following,  then  inspect  the  data  for  duplicate  records  after  each  of 
the  four  sorts: 

(a)  Last  Name,  then  First  Name 


**  Wc  did  not  have  any  trained  personnel  to  do  this  coding,  and  there  wasn’t  enough  time  to  train  and  oversee 
coding  of  the  records  for  the  48th  ATH,  so  this  was  not  done.  The  majority  of  records  for  the  previous  two 
contingents  had  been  coded,  and  this  information  was  entered. 

*2  See  Tab  F  for  examples  of  how  the  categorization  was  done  for  Medical  Inpatients. 
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(b)  First  Name,  then  Last  Name 

(c)  ID  Number,  then  by  either  Last  Name  or  First  Name 

(d)  ID  Number,  then  by  Nation,  then  by  either  Last  Name  or  First  Name 

(2)  When  a  duplicate  is  found,  keep  the  record  that  has  the  most  complete  or  accurate 
data,  and  add  any  new  data  that  may  be  foimd  in  the  duplicate.  Then,  remove  all  data 
from  the  duplicate  entry,  except  the  Patient  Sequence  Number.  Do  not  delete  the 
record  entirely^'^.  In  the  Last  Name  field,  type  a  space,  followed  by  ‘Use  #  ’  followed 
by  the  Sequence  Number  of  the  record  that  is  being  kept.  This  way,  if  one  looks  for 
the  Sequence  number  of  the  duplicate,  no  empty  record  it  will  acts  as  a  pointer  to  the 
record  that  actually  contains  the  patient’s  data.  The  initial  space  causes  these  records 
to  sort  out  together. 

b.  Outpatient  Visits  Data  Entry  form. 

(1)  Sort  by  Patient  Sequence  Number,  then  by  Date  of  Visit,  then  by  Time  of  Visit.  When 
an  apparent  duplicate  is  found  check  the  Clinic  and  Diagnosis  fields ,  since  a  patient 
may  have  been  seen  at  more  than  one  clinic  on  a  given  day,  for  a  different  problem. 

In  this  case,  the  records  are  not  actually  duplicates  of  each  other.  If  the  presenting 
problem  is  the  same,  and  the  patient  was  seen  in  the  ER  and  immediately  referred  to 
another  clinic  for  further  workup  and  treatment,  there  should  only  be  one  entry  for  the 
referral  clinic.  The  duplicate  ER  entry  should  be  removed  as  outlined  in  the  next  step. 
However,  if  the  patient  received  treatment  in  the  ER  prior  to  being  referred  to  another 
clinic,  then  both  the  ER  and  referral  clinic  entries  are  valid  and  both  should  be  kept. 

In  this  case  the  Referred  box  should  be  checked  in  the  referral  clinic  entry.  Also,  see 
that  the  Follow-Up  box  is  checked  when  multiple  follow-up  visits  for  the  same 
problem  are  found  (see  item  2.a.(6)  above). 

(2)  If  a  duplicate  is  found,  transfer  any  new  data  that  may  be  found  in  the  duplicate  to  the 
record  that  is  being  kept.  Then  remove  all  data  from  the  duplicate  entry,  except  the 
Visit  ro  Number.  Do  not  delete  the  record  entirely^\  Enter  Patient  Sequence  Number 
2 1  (a  dummy  patient  record),  which  will  put  the  phrase  ‘Leave  empty’  in  the  Last 
Name  field.  It  is  particularly  important  that  the  Date  of  Visit,  Diagnostic  Category, 
Admitted  and  Accident?  fields  are  empty  or  negative  in  these  records  •5. 

c.  Creating  Outpatient  Visit  Entries  for  Direct  Admissions 

(1)  Open  the  following  query  and  forms  in  the  datasheet  view  and  size  the  windows  so 
that  the  screen  is  split  in  three  horizontally: 

(a)  A&D  I  Outpt  query .  This  query  lists  all  of  the  admissions,  and  only  those 
outpatient  visits  for  which  there  is  a  match  on  the  Patient  Sequence  Number  field. 
Therefore,  for  each  patient  admitted  to  the  MASH,  there  is  a  record  created  for 
each  of  his  outpatient  visits,  listing  the  last  name,  ^te  of  admission,  register 
number,  and  date  of  outpatient  visit. 

(b)  Transfer  A&D  Info  form.  This  is  a  copy  of  the  A&D  form  with  the  extraneous 
columns  hidden. 

(c)  Outpatient  Visits  Data  Entry  form.  This  is  the  standard  form  used  for  entering 
outpatient  visit  data. 


This  is  because  this  Patient  Sequence  Number  has  already  been  written  on  the  paper  documentation  for  an 
outpatient  visit.  If  someone  were  to  use  that  document  to  look  up  information  on  that  patient,  the  ‘retired’ 
sequence  number  will  still  exist  and  contain  the  pointer  to  the  correct  number. 

These  ‘empty’  records  can  be  used  by  the  SysOps  when  creating  outpatient  entries  for  inpatients  who  lack  them. 
This  will  prevent  these  records  from  being  counted  in  the  summary  reports. 
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(2)  Compare  Ae  date  of  admission  to  the  visit  dates  in  the  A&D  I  Outpt  query.  If  there  is 
no  match‘‘>  found  between  the  admission  date  and  one  of  the  visit  dates,  then  an 
outpatient  visit  entry  must  be  created  to  correspond  to  the  admission. 

(3)  Search  the  Transfer  A&D  Info  form  by  Register  Number  to  find  the  admission. 

(4)  fa  the  Cfatpatient  Visits  Data  Entry  form,  search  for  a  ‘dummy  record’  by  searching  in 
Indent  Sequence  Number  field  for  #21.  The  patient  name  for  the  dummy  record 
should  read  Leave  empty”.  We  generally  typed  ‘‘Duplicate  entry”  in  the  diagnosis 
field,  although  this  is  not  critical.  AH  other  fields  should  be  blank. 

(5)  Transfer  the  perti^nt  data  from  fae  Transfer  A&D  Info  form  to  the  Outpatient  Visits 
Data  Entry  form.  Change  the  Patient  Sequence  Number  from  #  21  to  the  one  in  the 
adimssicm  record.  Check  to  see  that  the  patient’s  name  that  appears  is  correct.  Do  not 
change  the  visit  number.  Transfer  the  following  data  from  the  admission  record  to  the 
outpatient  visit  record  (these  can  be  copied  and  pasted): 

(^)  Use  the  date  and  time  of  admission  as  the  date  and  time  of  visit. 

(b)  Choose  ‘Direct  Admission’  from  the  pop-up  menu  for  the  Clinic  field 

from  the  A&D  record;  the  treatment  can  be  entered  as 

Admit 

(d)  Enter  the  Primary  Dx  Cat  from  the  A&D  record  into  the  Dx  Category  field  in  the 
Outpatient  Visits  record. 

(e)  fr  tl^  vdue  in  the  Illness  Type  field  in  the  A&D  record  is  1,  then  check  the  box  in 
the  Battle  Injury  field  on  the  Outpatient  Visit  record. 

(f)  Check  the  Accident  box  in  the  Outpatient  Visit  record  where  appropriate. 

(g)  Be  sure  to  check  the  Admitted?  checkbox  in  the  Outpatient  Visit  record 

d.  Prostaff  Revi^  of  Visit  entries,  A&D  records,  and  Operations.  The  input  of  the 
profession  staff  in  verifying  records  is  critical  to  the  accuracy  of  the  data,  particularly 
since  we  did  not  have  trained  Medical  Records  Administrators. 

of  diagnoses  and  treatments.  This  is  a  particular  problem  with  the 
inpatient  records,  due  to  the  number  of  providers  involved  and 
often  illegible  handwriting. 

(2)  For  fapatient  records,  it  is  important  that  the  primary  diagnosis  is  listed  first,  since 
tms  diagno^s  is  what  is  categorized.  Also,  when  reports  are  generated,  it  is  easier  to 
list  just  the  first  diagnosis,  so  doing  this  will  provide  the  most  meaningful  report. 

(3)  Review  the  inpatient  records  to  ensure  that  the  diagnoses  and  procedures  are 
complete.  A  diagnosis  of  ‘multiple  trauma’  is  meaningless  for  a  patient  who  suffered 
a  tracfared  mandible,  bilateral  leg  amputations,  and  who  required  8  operative 
procedures  to  remove  pieces  of  shrapnel  from  various  wounds  after  a  mine  injury. 

(4)  Assign  and  verify  the  disease  categories,  paying  particular  attention  to  the  consistency 

of  the  assignments.  ^ 


Sneaker  Net.  pie  goal  of  the  pseudo-network  is  to  collect  the  data  entered  into  the  outlyin*^ 
computers  and  bnng  it  all  together  into  the  ‘master  copy’  on  the  SysOp’s  computer  and  to 
transfer  the  Pattern  Data  information  entered  into  the  Patient  Administration  computer  to  the 
outlying  machines.  This  transfer  of  data  is  earned  out  via  a  skeleton  copy  of  the  database. 


•6  Sometimes  there  is  a  visit  entry  just  a  day  or  two  prior  to  the  admission  date.  In  some  cases,  particularly  with 
admissions  for  elective  surgery,  this  outpatient  visit  is  the  required  entry  for  the  admission.  This  is  generally 
obvious  from  the  diagnosis  and  treatment  information. 


51 


Tab  H2.  Patient  Database  Management 


called  ‘Trans.mdb”  on  a  floppy  disk.  Generally,  only  the  four  primary  data  tables  are 
transferred,  so  you  would  work  only  with  the  database  listing  of  tables. 

a.  Steps  involved.  In  general,  there  are  three  operations  involved.  The  first  is  copying  the 
A&D  DATA  table  and  using  it  to  overwrite  an  earlier  version  of  that  table.  The  second  is 
copying  one  of  the  other  tables  and  appending  it  to  another  copy  of  the  samp  table.  In 
both  of  these  cases,  the  tables  are  copied  and  pasted  in  their  entirety  from  and  to  the 
database  lis^g  of  tables,  without  being  opened.  The  third  operation  involves  opening  a 
table,  selecting  a  subset  of  the  records^ ',  then  appending  them  to  a  copy  of  the  table.  This 
paste  append  operation  can  only  be  carried  out  into  the  table  while  it  is  opened. 

(1)  Patient  Administration  Computer.  Copy  the  entire  A&D  DATA  table,  and  the  new 
records  from  the  PATIENT  DATA  and  OUTPATIENT  DATA  tables  onto  the 
Transport  Disk. 


(a)  Open  the  cmrent  copy  of  the  database  on  the  C  drive,  and  put  the  Transport  Disk 
m  toe  B  drive.  Select  toe  A&D  DATA  table  from  toe  current  copy  of  toe  datab?ise 
and  copy  it,  using  the  Copy  command  on  toe  Edit  Menu.  It  is  also  wise  to  open 
toe  table,  go  to  toe  last  record  and  note  down  toe  number  of  records  in  toe  table  so 
that  the  transfer  can  later  be  verified.  Close  the  database  using  the  Close 
coi^and  in  the  File  menu.  Open  the  database  ‘Trans.mdb”  from  the  floppy, 
again  using  the  File  menu.  Often  the  this  database  is  listed  at  the  bottom  of  the 
File  menu  as  a  recently  opened  file.  It  will  open  showing  the  listing  of  tables. 

(b)  Choose  the  Paste  command  from  the  Edit  menu.  A  dialog  box  will  appear,  asking 
you  the  name  you  want  to  paste  the  table  as,  and  whether  you  want  to  paste  the 
structure  only,  the  structure  and  data,  or  to  append  data  to  an. existing  table.  Name 
the  table  to  be  pasted  ‘A&D  DATA’,  exactly.  Choose  to  paste  both  the  structure 
and  data  .  If  you  have  done  it  correctly  you  should  get  another  dialog  box  asking, 

Replace  existing  table  ‘A&D  DATA’?”  Click  ‘Yes’.  When  the  paste  is  complete, 
open  the  A&D  DATA  table,  go  to  the  last  record  and  verify  that  the  transfer  is 
complete. 


(c)  Close  ‘Trans.mdb”.  Reopen  the  current  database  on  the  C  drive,  and  open  the 
PATIEI^  DATA  table.  Go  to  the  last  record  and  note  down  the  number  of 
records  in  the  table.  The  Patient  Sequence  Number  should  match  the  total  number 
of  records.  Select  all  of  the  records  added  since  the  last  transfer  and  copy  them. 
Close  the  table.  A  dialog  box  will  state,  “You’ve  copied  a  large  amount  of  data  to 
the  clipboard.  Do  you  want  to  keep  this  data  on  the  clipboard?”  Click  ‘Yes’,  then 
close  the  database. 


(d)  Open  *Trans.mdb  and  the  PATIENT  DATA  table.  From  the  Edit  menu,  select 
Paste  Append.  This  will  append  the  previously  copied  records  to  the  table.  A 
dialog  box  will  tell  you,”You’ve  just  pasted  ...  jecord(s).  Choose  OK  to  save  your 
changes  or  Cancel  to  undo  your  changes.”  Click  ‘OK’  Check  the  highest 
Patient  Sequence  Number  to  verify  complete  transfer.  Close  ‘Trans.mdb”. 


(e)  Reopen  the  current  database  on  the  C  drive,  and  repeat  steps  (c)  and  (d)  with  the 
OUTPATIENT  DATA  table.  These  are  the  outpatient  visits  entered  by 


It  is  useful  to  keep  a  running  list  of  the  last  record  copied  for  each  table,  so  only  the  records  entered  since  the  last 
data  transfer  can  be  selected. 

This  is  the  only  time  in  this  process  that  you  will  choose  this  option,  in  order  to  overwrite  the  old  A&D  DATA 
table  with  the  new  one.  All  of  the  other  transfers  will  use  the  ‘Append  data’  option. 

If  you  inadvertently  try  to  paste  append  a  duplicate  record,  you  will  get  an  error  message  which  says  it  can  not  be 
done.  In  this  case,  click  the  OK  button.  You  may  also  choose  to  suppress  further  error  messages  if  many 
duplicate  records  were  chosen  for  appending.  At  the  end  of  the  paste  append,  another  dialog  box  will  appear 
saying  that  the  duplicate  records  will  be  put  into  a  table  called  ‘Paste  Errors.’  Creating  this  table  takes  forever,  so 
it  is  best  to  avoid  this  situation  by  keeping  track  of  which  records  have  already  been  transferred. 
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Orthopeics,  and  Physical  Therapy  clinics,  using  Visit  Numbers  which  are 
greater  that  15,000. 

(f)  When  tte  transfers  are  complete,  go  back  to  the  database  on  the  C  drive.  Go  to  the 
hstmg  of  Macros,  choose  the  ‘Trans  Tables  to  XLS’  macro,  and  click  on  the 
Run  butto^  Tins  will  dump  all  of  the  data  in  the  four  primary  tables  into  Excel 
files  on  the  C  dnve,  m  the  A&D  directory. 


^  records  from  the  ER  database 

u,  r  ^ble  onto  the  Transport  Disk,  and  copy  the  PATIENT  DATA 

table  from  the  Transport  database  to  the  ER  database. 

(a)  Open  Ae  currem  copy  of  the  database  on  the  G  drive,  and  put  the  Transport  Disk 
in  the  B^v^Open  the  OUTPATIENT  DATA  table,  and  go  to  the  highest  record 

u  10,00020.  Make  note  of  both  the  record  number 

md  the  Visit  ID  Number  of  this  record.  Select  all  of  the  records  added  since  the 
last  transfer  and  copy  them.  Close  the  table  and  the  database. 

(b)  Open  ‘Trans^db”  and  the  9UTPATIENT  DATA  table.  From  the  Edit  menu, 
^lect  P^te  Append.  ’Diis  will  append  the  previously  copied  records  to  the  table. 

ID  Number  to  verify  complete  transfer.  Qose  the 
UU  IrAriENT  DATA  table. 


(c)  While  in  “Trans.mdb”,  select  and  copy  the  entire  PATIENT  DATA  table.  Do  not 

^en  the  table  to  do  this,  just  select  it  from  the  database  listing  of  tables.  Close 
Trans.mdb  . 


(d)  Reopen  the  current  database  on  the  C  drive  and  choose  Paste  from  the  Edit  Menu. 
A  di^og  box  will  appear,  asking  you  ±e  name  you  want  to  paste  the  table  as,  and 
whether  you  want  to  paste  the  structure  only,  the  structure  and  data,  or  to  append 
data  to  existii^  table.  Choose  the  ‘Append  data  to  existing  table’  option  and  type 
in  the  n^e  of  the  existing  table;  in  this  case,  PATIENT  DATA.  Do  not  choose 

options  as  these  will  overwrite  the  existing  PATIENT  DATA 
.  A  diali^box  may  appear  stating  “Errors  were  encountered  copying  data: 
The  contents  of  fields  in  0  record(s)  were  deleted,  and  [a  certain  number  of 
records]  were  lost  due  to  key  violations.  Proceed  anyway?”  Do  not  worry,  the 
msc^ded  records  are  duplicates,  and  not  needed.  Click  ‘OK’.  Open  the  PATIENT 
DATA  table,  go  to  the  l^t  record  and  verify  that  the  transfer  was  complete.  Make 
^re  that  the  mghest  Patient  Sequence  Number  is  equal  to  the  last  record  number. 
Close  the  table. 


(e)  When  the  hansfers  ^e  complete,  stay  in  or  go  back  to  the  database  on  the  C  drive. 
Go  to  the  hsung  omacros,  choose  the  ‘Trans  Tables  to  XLS’  macro,  and  click  on 
c  1  r-?  button.  I^s  will  dump  all  of  the  data  in  the  four  primary  tables  into 
Excel  files  on  the  C  dnve,  in  the  A&D  directory. 

Computer  Append  the  new  records  from  the  OR  database 
A  Transport  Disk,  and  copy  the  PATIENT  DATA  and 

A&D  DATA  tables  from  Trans.mdb”  to  the  OR  database. 

(a)  Open  the  current  copy  of  the  database  on  the  C  drive,  and  put  the  Transport  Disk 
“  Cpen  the  OPERATIONS  table,  and  go  to  the  last  record.  Make 

note  of  both  the  record  number  and  the  OR  Case  Number  of  this  record.  Select  all 

of  the  records  added  since  the  last  transfer  and  copy  them.  Close  the  table  and  the 
QStED^C. 


^  This  is  because  all  outpatient  visits  entered  by  the  ER  are  assigned  visit  numbers  from  I  -  9999 
This  append  step  will  combine  the  entire  table  that  was  copied  with  the  existing  table,  rather  than  just  a  subset  of 
records.  However,  if  the  copied  table  contains  records  that  are  duplicates  of  those  in  the  existing  table  based 
upon  the  primary  key  value,  (Pauent  Sequence  Number,  in  this  case),  these  copied  records  will  be  discarded. 
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(b)  Open  ‘Trans.nidb”  and  the  OPERATIONS  table.  From  the  Edit  menu,  select 
Paste  Append.  This  will  append  the  previously  copied  recoids  to  the  table.  Check 
the  highest  OR  Case  Number  to  verify  complete  transfer.  Qose  the 
OPERATIONS  table. 

(c)  While  in  ‘Trans.mdb”,  select  and  copy  the  entire  PATIENT  DATA  table.  Do  not 
open  the  table  to  do  this,  just  select  it  from  the  database  listing  of  tables.  Close 
‘Trans.mdb”. 

(d)  Reopen  the  current  database  on  the  C  drive  and  choose  Paste  from  the  Edit  Menu. 
The  dialog  box  will  appear,  asking  you  the  name  you  want  to  paste  the  table  as, 
and  whether  you  want  to  paste  the  structure  only,  the  structure  and  or  to 
append  data  to  existing  table.  Choose  the  ‘Append  data  to  existing  table’  option 
and  type  in  the  name  of  the  existing  table;  in  this  case,  PATIENT  DATA.  Do  not 
choose  any  of  the  other  paste  options  as  these  will  overwrite  the  existing 
PATIENT  DATA  table.  A  dialog  box  may  appear  stating  “Errors  were  encountered 
copying  data:  The  contents  of  fields  in  0  record(s)  were  deleted,  and  [a  certain 
number  of  records]  were  lost  due  to  key  violations.  Proceed  anyway?”  Do  not 
worry,  the  discarded  records  are  duplicates,  and  not  needed.  Click  ‘OK’.  Open  the 
PATIENT  DATA  table,  go  to  the  last  record  and  verify  that  the  transfer  was 
complete.  Make  sure  that  the  highest  Patient  Sequence  Number  is  equal  to  the  last 
record  number.  Close  the  table  and  the  database. 

(e)  Reopen  “Trans.mdb”,  select  and  copy  the  A&D  DATA  table.  Close  “Trans.mdb” 
and  reopen  the  database  on  the  C  drive.  P^te  the  table  under  the  namp  A&D 
'.DATA,  choosing  the  ‘Paste  both  structure  and  data’  option,  in  order  to  overwrite 
the  original  table. 

(f)  When  the  transfers  are  complete  go  back  to  the  database  on  the  C  drive.  Go  to  the 
listing  of  Macros,  choose  the  ‘Trans  Tables  to  XLS’  macro,  and  click  on  the 
Run’  button.  Tlus  will  dump  all  of  the  data  in  the  four  primary  tables  into  Excel 
files  on  the  C  drive,  in  the  A&D  directoiy. 

(4)  SysOp  Computer.  Copy  the  A&D,  PATIENT  DATA,  OUTPATIENT  DATA  AND 

OPERATIONS  tables  from  the  Transport  Disk  to  the  master  copy  of  the  database  on 

the  C  drive. 

(a)  With  the  Transport  Disk  in  the  A  drive,  open  ‘Trans.mdb”.  Select  the  A&D  table 

Md  copy  it.  Close  “Trans.mdb”,  and  open  the  master  copy  of  the  database  on  the 
C  drive. 

(b)  Choose  the  Paste  command  from  the  Edit  menu.  A  dialog  box  will  appear,  asking 
you  the  name  you  want  to  paste  the  table  as,  and  whether  you  want  to  paste  the 
structure  only,  the  structure  and  data,  or  to  append  data  to  existing  table.  Name 
the  table  to  be  pasted  “A&D  DATA”,  exactly.  Choose  to  paste  both  the  structure 
and  data.  If  you  have  done  it  correctly  you  should  get  another  dialog  box  asking 
“Replace  existing  table  ‘A&D  DATA’?”  Click  ‘Yes’.  When  the  paste  is  complete, 
open  the  A&D  DATA  table,  go  to  the  last  record  and  verify  that  the  transfer  is 
complete. 

(c)  Close  the  master  database,  and  reopen  “Trans.mdb”.  Select  the  PATIENT  DATA 
table  and  copy  it.  Close  ‘Trans.mdb”. 

(d)  Reopen  the  master  database  on  the  C  drive  and  choose  Paste  from  the  Edit  Menu. 

A  dialog  box  will  appear,  asking  you  the  name  you  want  to  paste  the  table  as,  and 
whether  you  want  to  paste  the  structure  only,  the  structure  and  data,  or  to  append 
data  to  existing  table.  Choose  the  ‘Append  data  to  existing  table’  option  and  type 
m  the  name  of  the  existing  table;  in  this  case,  PATIENT  DATA.  Do  not  choose 
any  of  the  other  paste  options  as  these  will  overwrite  the  existing  PATIENT  DATA 
table.  A  dialog  box  may  appear  stating  “Errors  were  encountered  copying  data: 

The  contents  of  fields  in  0  record(s)  were  deleted,  and  [a  certain  number  of 
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recorck]  were  lost  due  to  key  violations.  Proceed  anyway?”  Do  not  worry  the 

duplicates,  and  not  needed.  Click  ‘OK’.  Open  the  PATffiNT 

Sim  transfer  was  complete.  Make 

Patient  Sequence  Number  is  equal  to  the  last  record  number. 

(e)  Repeat  steps  (c)  and  (d)  above  for  the  OUTPATIENT  DATA,  and  OPERATIONS 
SJiplete  *^sfer  is 

^  coinpiete  go  back  to  the  database  on  the  C  drive.  Go  to  the 

W  ‘Trans  Tables  to  XLS’  macro,  and  cUck  on  the 

fiUc  primary  tables  into  Excel 

files  on  the  C  dnve,  m  the  A&D  directory. 

b  Implications  of  appending  records.  With  the  exception  of  the  Ai&D  DATA  Table  all  data 

tecoiS^  °”*y  records.  Previously  enterol 

darabSe^  This  cames  two  major  implications  for  the  management  of  the 

™«S?®Py  of  IlK  database,  previously  entered  records  can 
only  be  edited  on  that  copy.  This  is  because  when  appending  a  table  to  the  master 
records,^  detenmned  by  comparing  the  primary  key  field,  are 
discarded,  even  if  other  fields  in  the  record  have  been  changed. 

Stef? ^Tf  primary  key  field  for  that  record  should  not  be 

deleted.  If  it  is,  the  record  will  be  regenerated  when  a  copy  of  the  table  from  another 
computer  is  appended.  Instead,  the  primary  key  field  is  kept  and  a  ‘dummy’  record  is 
created,  as  outlined  m  item  4.  above.  The  primary  keys  for  the  data  tables  are  Patient 

OUtPATmlS  n  ^  Number  for  the 

KT  K  ^  ^^TA  t^e.  Register  Number  for  the  A&D  DATA  table,  and  OR 
Case  Number  for  the  OPERATIONS  table. 

^sfer.  Since  there  is  no  real  network,  the  transfer  of  data  from  one 
mputer  to  another  is  episodic  rather  than  continuous.  Therefore,  the  SysOp  must  be 
aware  the  stams  of  data  entry  at  each  station  before  spending  the  2  -  3  Sura  rSed  to 
dara  across  the  stations.  It  is  also  important  that  the  data  enterera 
Coordinate  their  work  with  the  data  transfer  schedule.  For 
example,  in  order  to  produce  the  weekly  (Sunday  through  Saturday)  EUCOM  renort  of 
of  patients  by  disease  categories,  the  steps  outlined  below  must  occur,  ^d  in  the 

of  a  few  records  is  delayed,  for  instance  bSlse 
whiSiSFnn^  ?  t  7^  misplaced,  the  entire  report  is  either  inaccurate  or  delayed 

fim  tr^sfers  are  done.  Generally,  we  performed  data  transfer,  followed 

by  a  full  backup  (descnbed  in  item  6.  below)  every  Sunday,  Tuesday,  and  Thursday. 

nn  be  made  for  all  new  patients,  and  sequence  numbers  looked 

up  for  old  patients  seen  through  2400  hours  on  Saturday.  This  is  generally 
completed  by  Sunday  mormng.  ^  By 

d^for  the  patiente  seen  in  the  Orthopedics,  Physical  Therapy  and  Dental 
cLpleSd  b^SamS^y.'"*  Parent  Administration  computer.  This  is  generally 

(3)  The  SysOp  must  transfer  the  PATIENT  DATA  table  to  the  ER  computer  before  the 

(4)  The  visit  data  is  then  entered  by  the  ER  staff.  The  timing  of  this  is  dependent  unnn 
who  is  scheduled  to  work  in  the  ER,  since  not  all  of  the  ER  staff  h^  promi  caffe 


c. 
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°  Usually,  this  is  accomplished  by  Monday  morning  or 

(5)  The  SysOp  must  then  transfer  the  OUTPATIENT  DATA  table  from  the  ER  computer 
to  the  master  copy  of  the  database  on  the  SysOp’s  computer^^.  This  is  generally  done 
on  Monday  evening,  although  may  have  to  be  put  off  until  Tuesday  if  there  has  been 
some  delay  in  the  previous  steps. 

(6)  The  data  tables  are  then  checked  and  verified,  to  remove  duplicates,  and  correct 
omissions  due  to  direct  admissions. 

(7)  Concurrent  with  step  (6),  the  entries  are  reviewed  and  disease  categories  assigned. 
Even  though  the  EUCOM  report  is  limited  to  the  US  patients,  all  of  the  entries  are 
categorized,  since  these  will  be  needed  for  the  monthly  UNPROFOR  report  Where 
possible,  accident  categories  for  injuries  are  also  assigned,  although  these  are  not 
nnahzed  until  the  end  of  the  month,  since  this  often  requires  review  of  the  written 
documentation. 

(8)  At  this  point  the  EUCOM  report  can  be  generated.  The  data  is  fairly  accurate,  by  ihi.<; 
Ume,  although  changes  in  categories  occasionally  occur  due  to  errors  found  when  the 
data  IS  reviewed  agam  in  preparation  of  the  monthly  UNPROFOR  and  Accident 
reports. 

6.  Backing  Up,  Compacting  and  Repair  of  the  Database. 

a.  Use  of  the  Ti^sfer  Macro.  Microsoft  ACCESS  stores  aU  of  the  data  in  one  database  file, 
making  it  difficult  to  recover  the  data  if  that  file  becomes  cornipted23.  Therefore  the 
macro  Trans  Tables  to  XLS’  was  written.  Its  function  is  to  create  a  basic,  text-level 
bac^p  of  the  data  tables,  separate  from  the  database  file  itself.  This  is  done  by  dumping 
fte  four  main  data  tables  into  four  text  files  for  Microsoft  Excel.  These  tables  are  named: 

‘outptdat.xls’,  and  ‘patient_data.xls’.They  are  located  in  the 
A&D  directory  which  is  in  the  ACCESS  directory  on  the  Ci  dnve.The  dntn  enterers  are 
mstructed  to  run  the  macro  after  a  session  of  data  entry,  to  protect  their  work  until  the 
SysOp  can  transfer  the  data  to  the  master  copy  and  back  it  up  to  floppy  disks. 

b.  Compacting  Md  repairing  the  database.  Once  the  master  copy  of  the  database  has  been 
updated,  it  will  need  to  be  compacted,  since  the  process  of  pasting  tables  and  appending 
records  tends  to  generate  a  large  amount  of  unused  space.  Also  the  process  of  compacting 
allows  a  copy  of  the  database  to  be  made  under  a  new  name  which  facilitates  version 
control,  and  allows  the  repair  of  the  database  to  be  done-on  a  copy,  rather  than  the 
onginal.  As  described  in  item  5.c.  above,  this  is  done  approximately  every  other  day. 


In  practice,  each  of  Ae  data  transfers  described  involves  complete  synchronization  of  the  copies  of  the  Hnfnhacp 
on  the  Patient  Administration,  ER,  and  SysOp’s  computers,  rather  than  the  transfer  of  isolated  tables.  This  is 
done  in  order  to  avoid  having  to  keep  track  of  what  version  of  which  table  is  currently  on  which  computer.  Not 
only  would  this  be  an  organizational  nightmare,  but  the  potential  for  a  data-losing  error  is  too  great  With  the 
current  system,  all  data  transfer,  except  for  the  OR,  is  done  by  the  procedure  outlined  in  item  5.a.  above. 

Updating  the  computer  in  the  OR  can  be  done  less  frequently,  usually  once  per  week,  because  of  the  relatively 
low  volume  of  data. 

We  had  the  occasion  recently  to  use  the  macro  to  recover  all  of  the  A&D  DATA  table.  This  table  was  corrupted 
at  the  end  of  the  workday.  Just  before  a  routine  backup  was  due.  so  two  full  days  worth  of  data  entry  and 
corrections  were  at  stake.  This  occurred  because  a  second  copy  of  ACCESS  and  the  database  was  opened  in 
memory,  and  the  people  working  on  these  copies,  alternately  modified  the  same  table.  One  person  was  altering 
the  pnmary  key  field  of  the  table,  which  caused  the  program  to  tie  itself  into  knots  when  it  tried  to  rationalize  the 
changes  being  made.  While  the  table  could  not  be  opened,  or  otherwise  manipulated,  the  macro  was  able  to  dump 
Its  contents  to  an  Excel  file.  This  file  was  then  imported  back  into  the  database,  and  the  data  restored  (see  item  7 
below  for  a  escription  of  this  procedure). 
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(1)  After  all  of  the  from  the  outlying  databases  have  been  transferred  into  the  master 
copy  on  the  SysOp  s  computer,  close  the  database,  using  the  Qose  command  on  the 
r'lle  menu.  Then,  from  the  same  menu,  choose  the  Compact  Database  . . .  command. 

(2)  A  dialog  box  will  appear,  asking  which  database  to  compact.  Choose  the  most  current 
copy.  Another  dialog  box  will  appear,  asking  which  file  to  compact  the  database  into. 

Type  m  the  name  of  the  new  database  to  be  created  (see  item  6.c.  below  for  namine 
conventions).  ® 

(3)  ^er  the  compacting  is  completed,  choose  the  Repair  Database  ...  command  from 

the  File  menu.  A  dialog  box  will  appear  asking  which  file  to  repair.  Choose  the  newlv 
compacted  copy.  ^ 

c.  Version  Control.  With  multiple  versions  of  the  database  in  various  stages  of 
completeness  on  different  computers,  it  would  take  a  herculean  effort  to  keep  track  of 
which  version  where.  To  avoid  having  to  do  this,  version  control  conventions  are 
applied  o^y  to  the  master  copy  of  the  database  on  the  SysOp’s  computer.  Other  copies 
on  the  other  computers  are  considered  to  be  incomplete  and  different  from  other  copies, 
regardless  of  which  version  name  these  copies  cany. 

(1)  Naming  convention.  The  database  is  named  *A&D<ddmmm>.mdb’,  where 
<ddminm>  represents  the  date  on  which  the  database  was  compacted,  with  a  leading 
zero  for  the  day  and  the  month  represented  by  the  standard  three  letter  abbreviation 
for  example:  A&D06Mar.mdb. 

(2)  The  most  important  action  to  take  once  a  new  copy  of  the  database  has  been  named  is 
to  change  the  properties  setting  for  the  Windows  Program  Manager  icon  which  the 
data  enterers  use  to  access  the  current  copy  of  the  database^for  editing  and  assigning 
disease  catergories.  If  this  is  not  done,  then  all  of  the  modifications  will  be  done  to 
the  wrong  copy  of  the  database  and  will  have  to  be  redone,  as  there  is  no  way  of 
autom^clly  transferring  the  modifications  of  existing  records  to  the  most  current 
copy  of  the  database. 

d.  Bacldng  up  to  floppy  disks.  Currently,  the  compacted  database  is  approximately  3.6  Mb, 
n^umng  3  tugh  density  floppy  disks  for  backup.  Three  complete  backup  sets  are  rotated, 
^e  backup  is  accomplished  using  the  DOS  5.0  ‘backup’  command.  The  command  line 


Backup  C:\ACCESS\A&D\A&D<ddmmm>.mdb  A: 

where  “<ddmmra>“  symbolizes  the  correct  date  according  to  item  6.c.(2)  above^^. 

e.  Updating  Outlying  Data  Entry  Stations.  Periodically,  especially  when  a  significant 
amount  of  structural  development  of  the  database  was  done,  new  copies  of  the  database 
were  put  onto  the  outlying  computers.  Obviously,  data  entry  would  have  to  have  been 
suspended  between  the  time  that  the  data  was  transferred  from  the  outlying  computer  to 
the  niaster  copy,  and  the  time  that  the  new  copy  of  the  database  was  restored  to  the 
outlying  computer.  This  was  accomplished  by  restoring  the  latest  backup  copy  from 
floppy  disks,  using  the  DOS  command  line: 

Restore  B:  C:\ACCESS\A&D\*.*25 


^  The  pathname  for  all  copies  of  the  database  on  all  of  the  computers  was  kept  uniform  to  allow  the  ‘restore’ 
command  to  be  essentially  the  same  The  only  difference  between  the  computers  we  currently  have  is  the  floppy 
disk  drive  designation. 

25  Ibid. 
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Tab  H2.  Patient  Database  Management 

(1)  Remember  to  update  the  Properties  setting  under  the  File  menu  for  the  Windows 
Program  Manager  icon  which  the  data  enter ers  use  to  access  the  current  copy  of  the 
database,  in  order  to  prevent  data  entry  into  an  older  version. 

(2)  Be  sure  that  the  Outpatient  Visits  Data  Entry  form  used  on  the  ER  copy  is  limited  to 
only  showing  records  with  Visit  Numbers  less  than  10,000,  (see  footnote  20). 

f.  Housekeeping 

(1)  Cleaning  Up  Hard  Drives.  In  order  to  conserve  hard  disk  space  on  the  outlying 
computers,  to  allow  faster  operation  of  Windows  and  the  database,  older  versions  of 
the  database  were  deleted  from  these  computers  after  it  was  clear  that  there  were  no 
problems  with  the  updated  copy. 

(2)  Cleaning  up  Program  Manager  windows.  A  continuous  effort  was  required  to  keep  an 
arrangement  of  Program  Manager  windows  and  icons  which  made  the  location  of  the 
database  icon  obvious  to  the  non-Windows™  literate  users.  No  amount  of  exhortation 
pevented  others  from  ch^ging  the  layout.  These  transgressions  were  compounded 
by  these  users  also  enabling  the  ‘Save  settings  on  exit’  command  on  the  Windows 
Options  menu.  Therefore,  the  appropriate  Program  Manager  windows  and  icons 
arrangement  would  periodically  have  to  be  restored. 

7  Recovering  data  from  .XLS  backup  files.  Should  one  of  the  data  tables  or  the  entire  database 
become  corrupted,  the  data  entered  can  be  recovered  by  importing  the  Excel™  files  created 
by  the  ‘Trans  Tables  to  XLS’  macro. 

a.  Go  to  the  File  menu  and  choose  the  Iinport  command.  A  dialog  box  will  appear  asking 
for  the  format  of  the  data  source  to  be  imported.  Choose  Microsoft  Excel.  Another  di^og 
box  will  appear,  showing  a  Ust  of  files  whose  names  end  in  ‘.XLS’.  Choose  the  table  to 
be  restored,  (see  item  6.a.  above).  Another  dialog  box  will  appear,  giving  the  following 
options: 

(1)  Checkbox:  “First  Row  Contains  Field  Names”.  Click  this  box  to  indicate  ‘yes’. 

(2)  Table  Options:  Either  “Create  New  Table”  or  “Append  to  Existing  Table:  (Type  in 

name  of  existing  table)”.  The  option  you  choose  here  depends  upon  whether  you  have 
an  intact  copy  of  the  structure  of  the  table.  The  structure  of  the  table  can  be  copied 
from  an  older,  intact  copy  of  the  database  and  pasted  into  the  current  database  without 
the  data.  If  you  choose  to  do  that,  then  choose  the  “Append  to  Existing  Table:” 
option.  This  is  the  preferred  way  to  reconstruct  the  table,  as  this  will  preserve  the  field 
descriptions  and  the  specific  field  lenghts  assigned  when  the  table  was  developed. 
Alternatively,  you  can  choose  to  create  the  table  de  novo,  by  choosing  that  option,  but 
you  should  then  go  into  the  design  view  and  retype  the  field  descriptions,  and  readjust 
the  field  lenghts26  ^ 

b.  Once  the  table  has  been  reconstructed,  a  dialog  box  will  tell  you  how  many  records 
have  been  imported,  and  how  many  errors  were  encountered  (there  shouldn’t  be  any). 
You  will  then  have  to  reenter  any  records  entered  since  the  last  time  the  ‘Trans  Tables 
to  XLS’  macro  was  run. 


8.  Final  Word.  It  should  be  obvious  from  reading  this  section  that  much  of  the  care  and  feeding 
of  this  database  and  the  pseudo-network  requires  an  extraordinary  attention  to  detail  and 
precise  following  of  instructions  on  the  part  of  all  who  work  with  it,  regardless  of  their 
capabilities.  Therefore,  it  is  essential  that  the  SysOp  or  an  assistant  be  continuously  available 
for  troubleshooting,  and  open  to  answering  questions,  to  avoid  fatal,  data-threatening  errors. 


2^  This  information  can  be  found  in  Tab  H  3.  Database  Structure. 
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sA.  H  2.1  Patient  Data  Entry  Form 


Patient  Data  -  General  Information 


Sequence  No: 


Org: 


IFrench  Army,  Log  Bat 


Last  Name: 

First  Name:  , 

r - i 

^hhet: 

_ 1 

Title:  1 

SGT 

Sex: 

DOB:  j 

1/1 /70{ 

SSAN:  1 

j 

/  Nationality: 

: 

) 

Married:  ^ 

1 

Religion:  | 

|UN 

J 

Branch:  | 

Corps:  j 

Address  1:  [camp  PiesT* 
Address  2:  P 


Cltv:[ 
State/Provinee:  || 
Postal  Code:  T 
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|j»ol(-ii|i  'I'sililes  I'lir  Diagnoses  siiid  ’rrcaliiiciils 


1'rentmeiit  Cnt  Code  H 

m 

fn 

m 

m 

CN 

fN 

CN 

VD 

1 

1 

1 

1 

1 

1 

vn 

«ri 

CN 

e 

S£ 

s 

O 

o 

u] 

I  Endo 

Endo 

Endo 

1  Endo 

1  OrSurg 

OrSnrg 

OrSiirg 

OrSurg 

OrSurg 

OrSurg 

Prevent 

Perlo 

Perio 

Perio 

Reslor 

W 

O 

To 

a> 

u 

O 

To 

V 

o:: 

Reslor 

Reslor 

Drug 

Drug 

Drug 

OrSnrg 

Denial  Trenliiieiils 

Piilpoloniy 

Pulpecloniy 

Obturation  -  Anterior 

Obturation  -  Bicuspid 

Obturation  •  Molar 

Apicalectomy 

Simple  Extraction 

Sol)  Tissue  Extraction 

Partial  Bony  Extraction 

Full  Bony  Extraction 

Root  Tip  Bxlraction 

Biopsy 

Prophylaxis/  Type  2  Exam 

Scaling 

— — .  . 

Root  Pjaning 

Crown  Lengiilening 

Composite  Filling 

Amalgam  Filling 

Glass  iononier  Filling 

Temporary  Filling 

Recemculalioii 

Antibiotic 

NSAIA 

Narcotic 

Incision  &  Drainage 

Denial  Diagnoses 

Caries 

Fracture 

I  Irreversible  Pulpitis 

IReversible  Pulpitis 

OS 

"S. 

1 

ja 

1 

u 

Z 

1  Acute  Apical  Periodontitis 

1  Chronic  Apical  Periodontitis 

1  Acute  Apical  Abscess 

ICiiTonic  Apical  Abscess 

iGross  Car}es 

1  Impacted 

Partial  Impaction 

INon-Functional 

Non-Reslorable 

IChrofiic  Periodontitis 

Ciironic  Gingivitis 

Acute  Periodontal  Abscess 

Chronic  Periodontal  Abscess  I 

Odontogenic  InTectlon 

MaxHlofacial  Fracture 

Pericoronitis 

Prophylaxis /Type  2  Exam 
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Tab  H  1.2. 10  Database  Structure  -Diagnosis,  Procedure,  Treatment,  and  Urgency  Categories 


Inpatient  Diagnostic  Categories 

Organ  System  Category 

Organ  System  Cat  Code 

Abdominal  Surgery 

Abdo  Sur^ 

Allergy/Immunology 

Aller 

Anesthetic 

Anesth 

Bums 

Bums 

Cardiovascular 

Card 

Dermatologic 

Derm 

Ear,  Nose,  Throat 

ENT 

Endocrine 

Endocrine 

Endoscopy 

Endoscope 

Gastrointestinal 

GI 

General  Surgery 

GenSurg 

Hematologic 

Heme 

Infectious  Disease 

ID 

Ncphroiogic 

Renal 

Neurologic 

Neuro 

Neurosurgical 

Neurosurg 

Obstetrical/Gyn 

OB/GYN 

Oncol 

Oncol 

Ophathmologic 

Ophtho 

Oral  Surgery 

OralSurg 

Orthopedic 

Oitho 

Other/Unclassiiled 

Other 

PostOp  Care 

PostOp 

Psychiatric 

Psych 

Pulmonary 

Pulmon 

Rheumatologic 

Rheum 

Thoracic  Surgery 

Thor  Surg 

Uroiogic 

Urol 

Vascular  Surgery 

Vase  Surg 

Surgical  Procedure  Categories 

Procedure  Type 

Proced  Type  Code 

Abdominal 

Abdo 

Anesthetic 

Anes 

Bum 

Bum 

Ear,  Nose,  Throat 

ENT 

Endoscopic 

Endo 

General 

Gen 

Genitourinary 

GU 

Neurosurgical 

Neuro 

Obstetrical 

OB 

Oral  Surgical 

Oral 

Orthopedic 

Ortho 

Plastic 

Plasl 

Thoracic 

Thor 

Vascular 

Vase 

Dental  Treatment  Categories 


Drug  Therapy 

Endodontic 

Oral  Surgery 

Preventative 

Periodontic 

Restorative 
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Tab  H  2.2  Outpatient  Visits  Entry  Form 

Outpatient  Visits  Data  Entry 


Patient  Number;  |  o| 

Visit  Number; 

0 

Last  Name: 

Rrst  Name: 

Ml:  Epi: 

Title: 

Qrade: 

Sex: 

BIrthdate: 

SSAN: 

Nationality: 

Date  of  Viah:  [  Time  of  Visit:  |  |  CUnic:  |EH  |  Provider: 

Smokes:  j  [  Ru  up  to  date:  |  j  Tetanus  up  to  date;  |  |  Follow-up  /  Repeat  Visit?  Si 


Chief 

Complaint: 

Diagnosis  1: 
0iagnosts2: 
Diagnosis3: 
Treatmenti: 
Treatment2: 
Treatment3: 
Treatmentd: 
Treatments: 


Aeddent?  15  Accident  Cat:  | 

DCodel:  Dx  Category:  |  j 


DCode2: 

OCodeS: 


Reportable 

Disease?  ' 

Admitted?  SS 
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Tab  H  2.3  Ortho  Clinic  Visits  Entry  Form 

Ortho  Clinic  Visits  Entry 


Patient  Number: 


Vi«t  Numben  P  o| 


Last  Name: 

Hrst  Name: 

Ml:  Epi: 

Tide: 

Grade: 

Sex: 

Birthdate: 

a#  I 

SSAN: 

Nadonaiity: 

Acddent?  flE 
Accident  Cat: 


Chief 

Compiaint: 

Diagnosis  1: 
Diagnosis  2z 
Diagnosis  3: 

Treatment  1: 
Treatment  2: 
Treatment  3: 
Treatment  4: 
Treatment  5: 


COnic;  tOR 


Provider: 


PoUowHip  /  Repeat  Visit?  55 
Admitted?  W. 


Referred  from  another  cSnie  for 
the  seme  problem?: 


DCodel: 

OCode2: 

DCode3: 
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Tab  H  2.4  FT  Clinic  Visits  Entry  Form 


PT  Clinic  Visits  Entry 


Patient  Numben  0 

Viah  Numben 

0 

Laat  Name: 

Firat  Name: 

Ml:  Epi: 

Title: 

Grade: 

Sex: 

Birthdate: 

SSAN: 

Nationality: 

Date  of  Viah: 
Accident?  W. 
Accident  Cat:: 


Time  of  Viah:  |  )  Clinic:  |  Provider: 

FbUovtMjp  /  Repeat  Visit?  11  Inpatient?  H 

Referred  from  another  efinie  for 
the  aame  problem?: 


Chief 

Complaint: 


Diagnosia  1: 

DCodel: 

DIagnosia  2: 

DCode2: 

Diagnosis  3: 

DCodeS: 

Treatment  1: 

Treatment  2:  | 

Treatment  3:  | 

Treatment  4:  | 

Treatment  5:  | 
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Tab  H  2.5  Dental  Clinic  Visits  Entry  Form 


Dental  Clinic  Visits  Entry 


Patient  Number:  P  oj 

Visit  Number  P 

~~51 

Last  Nama: 

First  Name: 

Ml:  Grade: 

SSAN:  Sax: 

Birthdate: 

Nadonaiity: 

i 

X 

Date  of  Visit:  | 

Acddent?  HI 

Accident  Cat:  ^ 

Chief  j 
Cotnpiaim:  | 

Diagnosis  1: 
Diagnosis  2: 
Diagnosis  3: 


Treatment  1: 
Treatment  2x 
Treatment  3: 
Treatment  4: 
Treatment  5: 


Time  of  Visit: 


jCflnic:  jPE 


Providen 


Easter 


FoUowHip  /  Repeat  Visit?  HI 
Walk4n?  IS 


Referred  from  another  dinie  for 
the  same  problem?:  ^ 


Admitted?  IS 

DCod«1;| 
DCode2:j 
DCode3: 1 


-1 

Uroencv 

J 

\  Umetif  Im  i 

1 1  Non  Uroent  |  d  : 

:  1 

1  j  Becthre  |  O  i 

Treatment  Cateoorv 

1  ResieroHve  |  O 

Penodonttc 

\  Oral  Surgery  1 0 

Drug  inn 

I  Endodontic  |0 

Preventative  |C 
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Tab  H  2.6  A  and  D  Form 


Admission  and  Disposition  Form 


R«ai«ter  Numbar: 

0 

Patient  Number:  |  0 

UimmK 

SSN:  ^ 

Bnacb:  CorpK 

IMamc; 

DOB: 

Off: 

MI: 

Natlooalttjr: 

£pi: 

Addml: 

ntlK  Gndt:  j 

M>rTted:{B  j 

Data  of  Admtaaion:[ 

1  Date  of  Diaehafge:!  | 

DMTh:{ir 

;  Itinaae  Tvoe 

Tima  of  Admiaatonj  | 

Tima  of  Diacharge  j  j 

Sl/VSkSH 

II  BofHelnHirv 

D/C  Clark:  1 

1  Reportable  Diaaaaa7:iM 

l|  Disease  (1^ 

Primary  Providar; 

dZl 

pi»aaaa.Mi 

Diaane«e«: 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 

Proeadures: 

1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 
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Tab  H  2.7  OR  Data  Entry  Form 


Tab  H3.1  Database  Structure  -  Tables 

List  of  Tables  . 

A&D  DATA 
Accident  Categories 
Anesthetic  Types 
Battle  Injury  Type 
Clerks 
Clinics 

Dental  Diagnoses 
Dental  Treatments/Cats 
Dental  Urgenqr  Categories 
Diag  Cats-General 
Diagnosis  Organ  System 
Illness  Type 
Nations 

Non-Battle  Injury  Type 
OPERATIONS 
OR  Staff 

OR  Urgency  Categories 
Ortho  Diagnoses 
Ortho  Treatments 
OUTPATIENT  DATA 
PATIENT  DATA 
Providers 
PT  Diagnoses 
PT  Treatments 
Religions 

Surgical  Procedure  Types 
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Tab  H 2.1.1  Database  Structure  -Patient Data  Table 


PATIENT  DATA  TABLE 

Field  Name 

Type 

Lengt  Indexed  Comments 

SeqNo 

Integer 

2 

PziznazyKey  Unique  Patient  ID  Number  ' 

LName 

Text 

25 

Indexed  Patient's  Last  Name 

FName 

Text 

15 

Patient's  Hzst  Name 

MI 

Text 

5 

Fatitsit’s  NCddie  Ttirtiai 

Epi 

Text 

15 

^ithet,  ie^  nidmame 

Title 

Text 

10 

Title,  ie^  SCTT,  CPT,  Mr^  Ms. 

Grade 

Text 

2 

Nfilitaty  Grade,  ie.,  E5, 04 

Sex 

Text 

1 

MorF 

DOB 

Date/Tiine 

8 

Patient's  bizthdate 

SSAN 

Text 

15 

Indexed  Service  ID,  eg.,  social  secnti^#,  UN  ID# 

Nationality 

Text 

2 

Look-up  Link  2-letter  coimtzy  code  (Nations  Table) 

Race 

Text 

5 

Race  or  ethnic  group 

Mazzied 

Text 

1 

Mazzied?  Y,  N,  or  U 

Religion 

Text 

2 

Look-iq)Link  2-letterzeIigion  code  (Religions  Table) 

VIP 

Yes/No 

1 

Veiy  Important  Person?  Y  orN 

Civilian? 

Yes/No 

1 

Civilian?  Y  orN 

Bzazidi 

Text 

3 

Branch  of  Service-  A  for  Army,  AF  for  Air  Force,  etc. 

Corps 

Text 

5 

Org 

Text 

25 

Battalion,  eg.,  NEPBAT,  JORBAT,  RUSBAT,  etc. 

Addressl 

Text 

50 

Local  location 

Address! 

Text 

50 

Home  address,  primazily  for  US  contingent 

aty 

Text 

25 

City 

State 

Text 

25 

State,  County,  or  Province 

Counny 

Text 

50 

Counny 

Postal 

Text 

10 

Postal  Code 

Input  Qezk 

Text 

5 

Look-iq)  Link  Qerk  inpiiting  this  rfara  (Qexks  Table) 
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Tcb  H2.1^  Database  Structure  -  Outpatient  Data  Table 


OUTPATIENT  DATA  TABLE 


Fieid  Name 


ID 

integer  2 

PatientNo 

latter  2 

DOV 

Date/Time  8 

TOV 

Date/Iizne  8 

Type  Length  Indexed  Comments 


nmuoyKey  Visit  ID  Nnober 


_  fartnfrd  linV’fd  to  Patient  Segneneei^  Patient  Data 


Indexed  Date  of  Visit 


Clinic  Text 


Provider  Text 


Smokes  Text 


Fin  Text 


Tetanus  Text 


Rqjoitable  Disease?  Yes/No 


Accident?  Yes/No 


Accident  Category  Text 


Chief  Complaint  Memo 


Diagnosisl  Memo 


DCodel  Text 


Diagnosis3  Memo 


DCodeS  Text 


Treatment!  Memo 


Indexed  liineorVisit 


Look-igtlink  Clinic  ■wfaerepatjegfwas  sea  (dinics  Table) 

rmvIderre8poaableforti'^p”ti‘*"t 


_ aadal  letter  of  [yes>  no,  ornnknown] 


_ Fin  shot  tq)  to  date?  ty^n.onr] 


Tetamw  sfaotup  to  date?  [y,naOrii] 


Is  the  diagnosis  a  nportable  disease? 


Was  the  injury  an  aeddaxt? 


Look-i^Linic  Type  of  accident  (Accident  Cat^ones  Table) 


_ Reason  for  visit;  eire.iiiiigt5tnrg^  of 


first  Diagnosis 


ICD-9  Code,  First  Diagnosis 


Hurd  IKagnosis 


_ ICD-9  Code,  Third  Diagnosis 


First  Treatment 


Treatments  Memo 


Diagnostic  Category  Code  Text 


Follow-iq)  Yes/No 


Battle  Injury?  Yes/No 


Major  Injury?  Yes/No 


Ophthalmic?  Yes/No 


ETOH  Related?  Yes/No 


BI  Type  Byte 


NBIType  Byte 


Admitted?  Yes/No 


Urgency  Byte 


Walk-in?  Yesfl^o 


Dental  Treatment  Cat  Byte 


Referral?  Yes/No 


Fifih  Treatment 


Follow^iy  to  this  clinic  for  the  same  problem? 


Was  it  a  batUe  iz^niy 


_ *  major  injury-requiring  admission  or  operation 


Was  it  an  eye  injury 


Wasnqury  alcohol  related  on  the  part  ofthe  UN  member 


Look»iq)  Link  Mechanism  of  battle  ngm-y  (Battle  Inhiry  Type  Table! 


Look-i^Lmk  Mechanism  jofnon  battle  injury  (Non-Battle  Iipury  TypeTable) 


Was  patient  admitted? 


Look-iqiLink  For  dental  entries  only  (Dental  Urgency  Categories  Table) 


For  iCT  only 


Look-1^  Link  Type  of  Dental  treaaaat  (Dental  Treatmmt  Category  Codes  Table) 


Was  this  a  referral  iiom  another  clinic  for  the  same  problem? 


Tab  H  3.1.3  Database  Structure  -  AS/4/94  Data  Table 


A&D  DATA  TABLE 

Field  Name 

Type 

Lengdi  Indexed 

Comments 

Register# 

Long  Integer 

4 

Primary  Key 

Assigned  to  each  admission 

Patient# 

Integer 

2 

Indexed 

Linked  to  Patient  Sequence  #  in  Patient  Data  table 

DOA 

Date/Iime 

8 

Indexed 

Admission  Date 

TOA 

Date/Time 

8 

Admission  Time 

DOD 

Date/Tune 

8 

Time  of  Discharge /Death 

TOD/C 

Date/Inne 

8 

Date  of  Discharge  /  Death 

D/CCleik 

Text 

5 

LookHq)Lmk 

Disefaar^  Clerk  (Clerks  Table) 

PrimProv 

Text 

20 

ftimaiyKovider 

SWSI 

Yes/No 

1 

Seriously  111  /  Very  Seriously  10 

Death 

Yes/No 

1 

Death 

BIorDNBI 

Integer 

2 

Look-up  Unlc 

Battle,  Non  Battle  Injury  &  Disease  (Illness  Type  Table) 

Reportable  Disease? 

Yes/No 

1  . 

Reportable  I&ease 

Diagnosis  1 

Memo 

0 

First  Diagnosis 

DxCodel 

Text 

10 

ICD-9  Code,  First  Diagnosis 

— 

DiagnosislO 

Memo 

0 

Tenth  Diagnosis 

DxCodelO 

Text 

10 

ICD-9  Code,  Tenth  Diagnosis 

Procedure  1 

Memo 

0 

First  Procedure 

PCodel 

Text 

10 

ICD-9  Code,  Fust  Procedure 

... 

Procedure  10 

Memo 

0 

Tenth  Procedure 

PCodelO 

Text 

10 

ICD-9  Code,  Tenth  Procedure 

Primary  Diagnostic 
Category  Code 

Text 

5 

Look-up  IJnIr 

Primary  Diagnostic  Category  Code  (Diag  Cats-Genezal 
Table) 

Diag  Organ  System  Cat  1 

Text 

20 

Look<^Link 

(Sub)Specialty  code  for  diagnosis  1 

... 

...  Look-^  Linlr 

...  (Diagnosis  Organ  System  Table) 

Diag  Organ  System  Cat  10  Text 

20 

Look-up  YJnV 

(Sub)Specialty  code  for  diagnosis  10 
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Tab  H  2.1.4  Database.  Structure  -  Operations  Table 


OPERATIONS  TABLE 


Field  Name  Type 


OR  Case  #  Caniiler>Lojig 


Patient#  Integer 


Register#  Long  integer 


Room#  Text 


OperatioaDate  Date/Tsne 


Anesth  Start  Txoie  Date/Iime 


AziestiiRnd  Time  Date/Imie 


Surgery  Start  Time  Date/Time 


Surgery  End  Tune  Date/Time 


Nursn^  Start  Time  Date/Time 


Nursing  Time  Date/lime 


Diagnosis  1  Memo 


DxCode  1  Text 


Length  Indexed 


PnmaryKcy 


indexed 


Indexed 


Indexed 


8  Indexed 


8 


Indexed 


Comments 


Assigned  to  eirery  opertian 


linked  to  Patient  Sequence#  in  Patient  Data  Table 


Manually  looked  tqi  in  A  &D  table 


ER>  Ward,  Operating  Room  1  or  2 


Date  of  Operatum 


Anesthesia  Start  Time 


Anesthesia  End  Time 


Surgery  Start  Time 


Surgery  End  Time 


Nursing  Start  Time 


Nursing  End  Time 


First  Operative  Diagnosis 


ICD*9  Code,  First  Diagnosis 


Diagnosis  10 

Memo 

0 

Tenth  Operative  Diagnosis 

DxCode  10 

Text 

10 

ICD-9  Code,  Tenth  Diagnosis 

Circulator  1 


Surgical  Assistant  4  Text 


Anesthetic 


Procedure  1 


ProcedCode  1 


Proced  Type  1 


Surgeon  I 


Integer 


Memo 


Text 


Text 


Text 


Look-up  Link  Urgency  of  Operation  (OR  Urgency  Categories  Table) 


Circulating  StajBTl 


Ciicnl3tor4  Text  20 

Circulating  Sta£r4 

Sernb  1  Text  20 

Senibbed  Staff  1 

Scrub4  Text  20 

Scrubbed  Staff  4 

Anesthetist  1  Text  20 

Anesdiedstl 

Anesthetist  4  Text 

20 

Anesthetist4 

Surgical  Assistant  1  Text 

20 

Surgical  Assistant  1 

Surgical  Assistant  4 


Look-iqiLink  Type  of  Anesthetic  Administered  (Anesthetic  Types  Table) 


_ First  Procedure 


_  ICD*9  Procedure  Code,  Krst  Procedure 


Look-up  Link  First  Procedure  Type  (Surgical  Procedure  Type  Table) 


Surgeon  Performing  First  Procedure 


Procedure  10 


Memo 


Tenth  Procedure 


Tpb  H  2.1.4  Database  Stmcium  -  Operations  Table 


OPERATIONS  TABLE 

Field  Name 

Type 

Length  Lidexed  Comments 

Placed  Code  10 

Text 

10 

1CD«9  PxDcediBe  Code,  Tenth  Fncednie 

Pioced  Type  10 

Text 

5 

Look*iq>Lmk  Tenth  Procedme  Type  (Sntgxcai  Procedure  Type  Table) 

Su^ecm  10 

Text 

mSm 

Sux'geuu  Pexfonxxmg  Tentfi  rM’^cgdufc 

Transfostoa 

Yes/No 

1 

Txansfhsum  Givea 

Speenneos 

Memo 

Specimeas  Taken 

Drams 

Memo 

Location  of  Drams 

Tmplgftfg 

Memo 

Ordiopedic  Implgnte  Used 

Remarlcg 

Memo 

Remarks 
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i  au  i^uLuuuna  Mructure -Look-Up  Tables  List 


I  Anesthetic  Types 


AceirtnrtCategcay  Text  SO _ CanseofArH.^ 

ForAnesthetie  Option  Gmup on  ORData  t^v*rj>Fo 


'•orm 


Anesthetic  Type 


Text 


30 


TjipeofanesthesB 


AnesQietic  Type  Code  Byte 


Can  be  Jinked  to  OperaliDns  Tabic  'Anesthetic*  field 


Battle  Injtny  Type  Po^BattU  Injury  Option  Owup  on  A&D  ami DiaeCats.  Earn,  Fnrm^ 


BIxgniyType 


Text 


50 


Cause  nf  Battle  Tnjmy 


BIType# 


Byte 


link  via  qnenes  foriepotts 


Qerks  Source  for pop^  menu  on  Patient  Data  fn„i  pf 


arms 


Name 


Text 


20 


GJakfsaame 


fiutial 


Text 


link  to  fonns  via  Oaks  Sort  Query 


Qinics  Source  for pop^p  menu  on  Patient  Data  Entry  emdA^  n 


arms 


Abbreviatian 


Text 


2  RcimaryKey  linkto  fbrmsTia glwrie  Smt  Qm^y 


Descri^on 


Text 


SO 


Full  nnm^  gf  rlimr 


Dental  Diagnoses  Source  for  pop-up  menu  on  Dental  Clinic  Data  Entry  Ft 


arm 


Dental  Diagnoses 


Text 


80 


Cornmnn  Dental  Dtggnno»» 


Dental  Treatment  Category  Codes  For  Treatment  Cat  Option  Group  on  Dental  CUme  Data  Entry  Form 


Treatment  Category  Text 


10 


Category  of  Treatment 


Vestment  Cat  Code#  Byte 


_^tmaryKey  Linkto  Outpal  irnt  Data  Table  Dental  Treatment  Cat*  flH'^ 


Dental  Treatments/CatS  Source  for  pop-up  menu  on  Dental  Oime  Data  Entry  Form 


Dental  Treatments 


Text 


35 


Common  Dental  Treatments 


Inatnusa  Cati^ory  Text 


Category  of  Treatment 


Treatment  Cat  Code  It  Byte 


For  Reference  Only 


Dental  Urgency  Categories  For  Urgent^  Option  Group  on  Dental  Oinia  Bury  Ft 


arm 


Dtgeney  Category  Text 


20 


Urgat,  Non  Urgent  Acute,  or  Electire 


Urgency  Cat# 


Byte 


Link  to  Ouqrmimt  Data  Tdile  Urgency*  field 


Diag  CatS-General  Source  for  pop-up  menu  on  Diagnostic  Category-General  Entry  Form 


Ike  Category 


Text 


50 


Full  Name  of  lkagnostie  Category 


Dx  Cat  Code 


Text 


PnmaryKey  ^'^h>A&D  and  Outpatient  Data  Tables '(Eriniary) 
Diagnostic  Category  Codef  fields 


DxCatDescrqttion  Memo 


list  oflUnesses  Belonging  to  the  Cat^oty 


Order-UNFROFOR  Byte 


Sort  Order  for  UNFROFORRqtort  via  Diag  Cats-General 
Sort  Query 


QrdeF>USAFE 


Byte 


Sort  Order  for  USAFE/EUCOM  Rqjon  via  Diag  Cats-USAFEi 
Sort  Query 


Diagnosis  Organ  Syston  Source  for  pop-up  menus  on  A&D  Form 


Organ  System  Category  Text 


20 


(Sub)  Specialty  of  IXagnosis 


Organ  System  Cat  Code  Text 


10 


Illness  T3rpe 


For  Illness  Type  on  A&D  Form 


li^to  A&D  Data  Table  Diag  Organ  System  Caf  fields 


IQnessType 


Text 


15 


Battle  Injury,  Disease  or  Non  Battle  Injury 
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Tab  H  2.1.5  Database  Structure  -  Look-Up  tables  List 


_ _ Look-up  Tables  and  Pop-up  Menu  Sources 


Table  Field  Name _ Type  Length  Indexed  C:nninn.ti»c  "  ’ 


_ _ 52!^ _ !_ _ Ijnk  to  A&D  Data  Tabk’BI  or  DNBr  field 


Nations  Source  for  pop-up  menus  on  Patient  Data  Form  ■ 


PrimaiyKey  Linkto  Paficot  Data  Table  'Nationality' 


Non-Battle  Injury  Type  For Bauielnfuty  Option  Group  on  A&D  and Digg  Cats,  sltoy  Forms 

NBInpgyType  Text  SO  Cause  of  Non  Battle  Injiny  ~ 

NBIType#  ~  Link  via  queries  for  npoits 


Abbreriation 


_ Nation _ lexi  so  Rifi  name  of  Nation 


Non-Battle  Injury  Type 
NBIignry  Type 


NBI  Type  if 


ORStaff  Source  for  pop-up  menus  on  OR  Data  Entry  Form 


Name  Text  20 


Function  Code 


OR  Urgency  Categories 


tftgency  Category 


Urgency  Cat# 


Ortho  Diagnoses  S 


Diagnosis 


_  NameofStaffMember 

Integer  2  Sort  Code  for  OR  Data  Entry  via  OR  Cireni  Staff  Snrt  nn 

_ ^ _ SembStafirSortQnsies 


_ for  Urgent^  Option  Group  on  OR  Data  Entry  Form 


‘y  _ 20 _  Urgency  of  Operation 


_ J _ Linkto  Operations  Table  'Urgency*  field 

Source  for  pop-up  menu  on  Ortho  Clinic  Entry  Form  ^ 

25  Common  Orthopedic 


Ortho  Treatments  Source  for  pop-up  menu  on  Ortho  Clinic  Entry  Form 


_ Ortho  Treatments  Text  40  Common  Orthopedic  treatments 


Providers  Source  for  pop-up  menu  on  Clinic  Data,  OR  Data  ondA&D  Entry  Forms 


_ ftovider _  Text  20  PrimaryKey  Name  of  Provider 


_ _ I _  Sort  Code  for  ORData  Table  via  OR  Provider  Sort  Query 


Ortho  Sort  if  Byte  1  Code  for  Qthio  Clinic  Visit  Entry  Table  via  Ortho 

_ ftovidcT  Sort  Quay 

PTSort#  Byte  1  Sort  Code  for  FT  Clinic  Visit  Eairy  Table  via  PT  Provider 

_ Sort  Query 


PTSort# 


Dental  Sort  Byte  1  Code  for  Dental  Clinic  Visit  Entry  Table  via  Dental 

' _ Provider  Sort  Query 


FT  Diagnoses _ Source  for  pop-up  menu  on  PT  Clinic  Entry  Form 


_ PTDx/Assesment  Text  SO  CommcaiPhysibdIhetq)y 

FT  Treatments  Source  for  pop-up  menu  on  PTCUnic  Entry  Form 


PTTr>m«»— Text  SO _ Common  Physical  Therapy  treatments 


Religions  Source  for  pop-up  menu  on  Patient  Data  Form 


_ Abbreviation _ Tort _ 2  PrimaryKey  Link  to  Patient  Data 'Religion' field 


_ Relisinn _ Text  SO  Nameofn.Hg4Z 


Surgical  Procedure  Types  Source  for  pop-up  merm  on  ORData  Entry  Form 


_ _ Procedure  Type  Text _ 20 _  Surgical  Specialty  of  Procedure 


'  '  ft®ced  Type  Code  Text  5 _  Link  to  Operations  Table  "Proced  Type' 
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.  TOD  « j.i.u  jjaiaoase  oxrucxarc  -  Look-up  lable  Contents  -  J^ations  and  Religions 


Look-up  Tables  for  Nationalities  and  Religions 


Abbreviation 

Nation 

1  Abbreviation 

Nation 

Abbreviation 

Religion 

"  AR 

Argentina 

U 

Libia 

AD 

Seventh  Day  Adventist 

AU 

Australia 

LU 

Luxembezg 

BA 

B^dst 

BE 

Belginm 

MA 

Malaysia 

BU 

Buddhist 

BG 

Bangladesh 

NT 

Nigeria 

CE 

Church  of  England 

BR 

Brazil 

NL 

Netherlands 

CH 

Christian 

BU 

Bunaa 

NO 

Norway 

EP 

]^iscopalian 

CH 

China 

NP 

Nqsal 

GO 

Greek  Orthodox 

CN 

NZ 

New  Zealand 

HI 

Hindu 

CO 

Columbia 

PE 

Peru 

IS 

Tslatn 

CZ 

Czech  Republic 

PI 

Philipines 

JE 

Jewish 

DK 

Dexunaxk 

PK 

Pakistan 

JW 

Jchovah*s  Witness 

EG 

Egypt 

PO 

Poland 

MO 

Latter  Day  Saints 

EQ 

Equador 

PR 

Portugal 

NO 

None 

ET 

Ethiopia 

RO 

Romulan 

OR 

Orthodox 

n 

Finland 

RU 

Russia 

PD 

Pagan  Druid 

FR 

France 

SA 

Saudi  Arabia 

PR 

Protestant 

GB 

Great  Britain 

SI 

Switzerland 

RC 

Roman  Catholic 

GE 

Germany 

SK 

Slovakian 

RO 

Russian  Orthodox 

C31 

SP 

Spain 

SO 

*  Serbian  Orthodox 

GU 

Guyana 

SU 

Sudan 

UN 

Unknown 

HR 

Croatia 

SV 

Slovenian 

WI 

Wlcca 

IC 

Iceland 

SW 

Sweden 

IN 

Tndia 

TU 

Tunisia 

IQ 

Iraq 

UG 

Uruguay 

m. 

Ireland 

UN 

Unknown 

IT 

Italy 

OR 

Ukraine 

XA 

Jamaica 

US 

United  States 

JO 

Jordan 

VE 

Venezuela 

KE 

Kenya 

ZA 

Ziare 

L£ 

Ldjanon 

Oinics 


iab  Hi,  l.V  Uatahme  Utrucluie  -  Look-Up  ioble  L'onfcnfx  -  Diagnoses  and  Trealnients 


u 
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Tab  tib.  J.s  Database  Structure  -  Look-Up  Table  Contents  -  OR  Data  Entry  Form  Pop-Up  Menus  and 
Option  Grottps 


Operative  Urgency  Categories 

Urgenqr  Category 

Urgenq'  Cat  # 

Urgent 

1 

Non  Urgent  Acute 

2 

Elective 

3 

OR  Staff 

(1  =  Nurse;  2  =  Tech) 

Name 

Function  Code 

Swansfaurg 

1 

McDaniel 

1 

Jones 

1 

Tackman 

1 

Sargent 

2 

Taylor 

2 

Balbi 

2 

Veeder 

2 

Chapman 

2 

Ferree 

2 

Carter 

2 

Spencer 

2 

Ceperich 

2 

Trexler 

2 

Alexander 

2 

Nason 

2 

I  ;ker 

2 

Smailman 

2 

Maynard 

2 

Type  of  Anesthesia 

Anesthetic  Type 

Anesthetic  Type  Code 

General 

1 

Monitored 

2 

Stand-by 

3 

Spinal 

4 

Epidural 

5 

Bier  Block 

6 

Axillary  Block 

7 

None 

8 
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Tab  H3, 1. 12  Database  Structure  ~  Illness,  Accident  and  Injury  Categories 


Illness  Types  and  Accident  Categories 


Ulness  Type 

Type# 

Battle  injury 

1 

Disease 

2 

Non-battle  injury 

3 

Accident  Category 

Vehicular  accident 
Sports 
h^c 
Indust 
Fights 
Falls 

Unknown 


Battle  and  Non  Battle  Injury  Types 


B  Injury  Type 

BIType# 

NB  Injury  Type 

NBIType# 

Gun  shot  wound 

1 

Vehicular 

1 

Mine 

2 

Sports 

2 

Artillaiy 

3 

Other 

3 

Other 

4 

Unknown 

4 

j  Unknown 

5 

31 


Tab  H3,2  Database  Structure  -  Queries 


_ _ Queries  List  _ 

A&D  I  Outpt 

Accid  Outpt  Report  Q 

Accident  Categories  by  Nationality 

Accident  Category  Sort 

Anesthsia  Provider  Sort 

Battle  Injury  Total 

BI  by  Nation  sort 

BITotals/ER 

Clerks  Sort 

ClinicSort 

Database  Overview 

Dental  Dx  Sort  ' 

Dental  Tx  Cats-  US 

Dental  Tx  Cats-Other  UN 

Dental  Tx  Cats-UN/US,AD/Civ 

Dental  Provider  Sort 

Dental  Tx  Sort 

Diag  Cats-General  Sort 

Diag  Cats-Individual  Clinic  Monthly  Re 

Diag  Cats-USAFE  Sort 

Diag  Organ  System  Sort 

Diagnostic  Cat-Injury  Report 

Diagnostic  Categories  by  Nation/ER 

Diagnostic  Categories-Gen  Entry/^epor 

Diagnostic  Categories-USAFE  Report  S 

Diagnostic  Category/DENTAL 

Diagnostic  Category/MED 

Med  Inpatient  Report  Sort 

Monthly  Dx  Cats  by  Nation  sort 

NationSort 

NBI  by  Nation  sort 

NBI  Totals  by  Nation  sort 

NBI  Totals/ER 
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Tab  H3.2  Database  Structure  -  Queries 


Queries  List 

OR  Circul  Staff  Sort 
OR  Provider  Sort 
OR  Scrub  Staff  Sort 
Ortho  Dx  Sort 
Ortho  Provider  Sort 
Ortho  Tx  Sort 
Outpatient  Pediatrics  sort 
Patient  U  A&D 

,  Patient  U  A&D  for  Daily  Report 
Patient  U  Operations 
Patient  U  Outpatient  for  ER 
Patient  U  Outpatient 
ProviderSort 
PT  Dx  Sort 
PT  Provider  Sort 
PTTxSort 
ReligionSort 

Surgical  Procedure  Type  Sort 


83 
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Jhb  113.2. 1  Dolnhate  StrucUire  -  Query  lietaih 
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Dental  Tx  Cats* 
Other  UN 

Treatment 

Category 

• 

Joint 

Inner 

Sourct  Table 
Field 

Dental  Tx  Cats* 
US 

Treatment 

Category 

Source  Table  /  Query 

Diagnostic  Category  / 
DENTAL 

Diagnoslio  Category  / 
DENTAL 

Diagnostic  Category  / 
DENTAL 

Diagnostic  Category  / 
DENTAL 

Diagnostic  Category  / 
DENTAL 

Diagnostic  Category  / 
DENTAL 

Diagnostic  Category  / 
DENTAL 

Diagnostic  Category  / 
DENTAL 
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UN 
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Dental 
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Dental 

Treatments/Cats 

Dental 
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Field  Name 

US  Civilian 

(Nationality) 

Q 

Treatment  Category 

UN  AD 

UN  Civilian 

(Nationality) 

9 

Treatment  Category 

US  AD 

UN  AD 

US  Civilian 

UN  Civilian 

Dental  Treatments 

Treatment  Category 
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Pivot 
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Count 
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Count 

Ascending 
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15 
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Tab  113.2. 1  Databate  Structure  -  Query  Detaih 
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Tab  113.2.  /  Dnfnbaie  Sinicfure  -  Qitcry  Ihrtall.t 
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Outpatient  Data 

PatientNo 

Diag  Catt-Qenoral 

Dx  Cat  Coda 

1  Battle  Injury  Typo 

1  Bl  Type  1 
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1  Battle  Injury  Type 
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Outpatient  Data  | 

PatientNo 
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PatientNo  | 
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Field 

Patient  Data 
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Outpatient  Data 

Diagnostic 
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\  Outpatient  Data 

1  Bl  Type 

Outpatient  Data 

NBI  Typb 

Patient  Data 

SeqNo 

Patient  Data  | 

SeqNo 

Outpatient  Data 

Sourct  Table  /  Query 

Diagnosis  Organ 

Systom 

Outpatient  Data 

Outpatient  Data 

Outpatient  Data 

Outpatient  Data 

Outpatient  Data 

jOutpatient  Data 

To 
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Outpatient  Data 

Outpatient  Data 
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Organ  System 
Category 
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Q. 

Follow-up 

Accident? 

_ 

jAccident  Category 

Dx  Category 

Battle  Injury? 

Diagnostic  Category 
Code 

Major  Injury? 

Bl  Type 

B  Injury  Type 

NBI  Type 

NB  Injury  Typo 

ETON  Related?  '  | 

Admitted?  | 
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